Secure smart card operations

ABSTRACT

The present disclosure is directed to facilitating cashless digital transactions. In one embodiment, a gaming machine includes: (1) a memory storing a first credit balance representing an amount of credit available for wagering; (2) a communication interface configured to communicate with a portable electronic device storing a second credit balance representing a second amount of credit available on the portable electronic device; and (3) a secure transaction device configured to: (a) transmit to the portable electronic device a request to update the second credit balance, the request including security authorization information, (b) receive from the portable electronic device an indication that the second amount of credit has been updated in accordance with the request when it is determined that the security authorization information complies with one or more security authorization requirements, and (c) update the first credit balance stored in the first memory device in accordance with the request.

PRIORITY CLAIM

This application is a continuation of and claims priority to and thebenefit of U.S. patent application Ser. No. 12/756,396, filed on Apr. 8,2010, which is a continuation-in-part of and claims priority to and thebenefit of U.S. patent application Ser. No. 11/967,916, filed on Dec.31, 2007, which issued as U.S. Pat. No. 8,463,711 on Jun. 11, 2013,which claims priority to and the benefit of U.S. Provisional PatentApplication No. 60/904,017, filed on Feb. 27, 2007, now expired, theentire contents of each of which are incorporated herein by reference.

TECHNICAL FIELD

The present invention relates generally to gaming devices and systems,and more specifically to security methods for gaming devices.

BACKGROUND OF THE INVENTION

There are a wide variety of associated devices that can be connected toa gaming machine such as a slot machine or video poker machine. Someexamples of these devices are lights, ticket printers, card readers,speakers, bill validators, ticket readers, coin acceptors, displaypanels, key pads, coin hoppers and button pads. Many of these devicesare built into the gaming machine or components associated with thegaming machine such as a top box which usually sits on top of the gamingmachine.

Typically, utilizing a master gaming controller, the gaming machinecontrols various combinations of devices that allow a player to play agame on the gaming machine and also encourage game play on the gamingmachine. For example, a game played on a gaming machine usually requiresa player to input money or indicia of credit into the gaming machine,indicate a wager amount, and initiate a game play. These steps requirethe gaming machine to control input devices, including bill validatorsand coin acceptors, to accept money into the gaming machine andrecognize user inputs from devices, including key pads and button pads,to determine the wager amount and initiate game play. After game playhas been initiated, the gaming machine determines a game outcome,presents the game outcome to the player and may dispense an award ofsome type depending on the outcome of the game.

As technology in the gaming industry progresses, the traditional methodof dispensing coins or tokens as awards for winning game outcomes isbeing supplemented by ticket dispensers which print ticket vouchers thatmay be exchanged for cash or accepted as credit of indicia in othergaming machines for additional game play. An award ticket system, whichallows award ticket vouchers to be dispensed and utilized by othergaming machines, increases the operational efficiency of maintaining agaming machine and simplifies the player pay out process. An example ofan award ticket system is the EZ pay ticket system by IGT of Reno, Nev.Award ticket systems and systems using other cashless mediums, such assmart cards, are referred to as cashless systems.

Cashless systems, such as the EZ pay ticket system, provide advantagesto both game players and casino operators. For example, many playersfind it more convenient to carry an award ticket than a large number ofcoins. For gaming machine operators cashless systems tend to reducegaming machine operating costs. For example, the infrastructure neededto remove and count indicia of credit (e.g. coins, tokens, bills) fromthe gaming machine may be eliminated or minimized when it is replacedwith a cashless system, which reduces the gaming machine operatingcosts. Further, coin dust, which is potentially damaging to thecomponents of the gaming machine (e.g. electronic components) may beeliminated or minimized when coin acceptors are replaced with thecashless system.

A concern in any cashless system is security. Typically, cashlessinstruments store a cash value that is ultimately redeemable for cash.Unfortunately, cashless instruments, such as printed tickets or smartcards, can be vulnerable to fraud in some instances, particularly wheresuch instruments or systems of instruments are used in relatively simpleformats or security architectures. A gaming entity, such as casino, thatissues the cashless instrument can be liable for any cash that isobtained using the cashless instrument whether the cashless instrumentis used in a valid or a fraudulent manner. While existing systems andmethods for providing cashless instruments associated with gamingdevices and gaming systems have been adequate in the past, improvementsare usually welcomed and encouraged that reduce the potential and/orlimit damages resulting from fraud. In light of the foregoing, it isthus desirable to develop methods and systems for preventing or reducingfraud and other potential problems associated with cashless instruments.

Conventional smart cards used for cashless gaming often employ theGemplus file format model of storing and capturing information. TheGemplus format permits a credit balance, along with other information,to be stored on a Gemplus card. Credit can be deducted from a Gempluscard for use in gaming or for small transactions, such as with merchantswho are not connected with a credit card network. If a Gemplus card isstolen, only money that is stored on the Gemplus card will be lost.

An application running on a device communicating with a Gemplus card isused to update and retrieve data from the Gemplus card. For example, theapplication may be running on a card reader or a device in communicationwith the card reader. Updating values stored on a Gemplus card may beaccomplished using symmetric key encryption (e.g., 3DES). The Gempluscard updates the credit balance stored on the Gemplus card if therequest is encrypted with the appropriate cryptographic key. However, ifany applications were permitted to add to a balance stored on the card,then a user possessing such a key would be able to add value to a cardwithout paying. Thus, in the Gemplus system, different symmetric keysare used for the debiting and crediting functions. In this way, manysystems have the ability to retransfer credit from Gemplus cards, whilethe ability to add credit to Gemplus cards is limited to trustedparties.

These conventional techniques suffer from several drawbacks. Forexample, if a cryptographic key for updating credit balances on aGemplus card is discovered by an attacker, then all Gemplus cards thatuse that cryptographic key are compromised, since the cryptosystem issymmetric. As another example, a Gemplus card verifies that a request toupdate a value is encrypted with the correct key, but not whether therequester is authorized to make the request. As yet another example,communication with Gemplus cards is susceptible to interception andalteration (e.g., at the card read/write interface of the card reader).Due to these and other weaknesses, hackers have been able to cheat theGemplus system for profit.

In addition, the limited capabilities of the Gemplus system make itunsuitable for cashless gaming. For example, the Gemplus format providesonly three bytes of memory for storing credit. Thus, a Gemplus card maybe used for small purchases or low-credit gaming, but it may haveinsufficient memory for storing larger amounts of credit. As anotherexample, the limitations on adding credit to a Gemplus card mean that aplayer may not be able to use a Gemplus card to cash out a gamingmachine after a gaming session. That is, the credit value stored on thegaming machine may not be moved to the Gemplus card. As yet anotherexample, the Gemplus system uses proprietary hardware for Gemplus cardsthat is only available from licensed suppliers, thus resulting inincreased cost for each card.

Thus, a need exists for cashless gaming techniques having expandedcapabilities and greater security.

SUMMARY OF THE INVENTION

Various embodiments described or referenced herein are directed todifferent devices, methods, systems, and computer program products forfacilitating cashless digital transactions. In some embodiments,devices, methods, systems, and computer program products may beconfigured or designed for use in a casino environment.

According to various embodiments, a wager-based gaming machine mayinclude a master gaming controller configured to control one or moregames of chance; a wager input device operable to receive an indicationof a wager to play the one or more games of chance; a value outputdevice configured to output an indication of value including an awardbased on play of the one or more games of chance; a first memory devicecapable of storing a first credit balance representing a first amount ofcredit available for wagering to play the one or more games of chance;and/or a communication interface configured to communicate with aportable electronic device having a first processor and a second memorydevice, the second memory device capable of storing a second creditbalance representing a second amount of credit available on the portableelectronic device. A wager-based gaming machine may also include asecure transaction device comprising a second processor and a thirdmemory device, the processor operable to transmit to the portableelectronic device, via the communication interface, a first request toupdate the second credit balance, the first request including securityauthorization information; receive from the portable electronic device,via the communication interface, when it is determined that the securityauthorization information complies with one or more securityauthorization requirements, an indication that the second amount ofcredit has been updated in accordance with the request; and update thefirst credit balance stored in the first memory device in accordancewith the request.

In at least one embodiment, a method of operating a wager-based gamingmachine may include storing, in a first memory device on the gamingmachine, a first credit balance representing a first amount of creditavailable for wagering to play the one or more games of chance availableon the gaming machine; transmitting from a secure transaction device onthe gaming machine, via a communication interface, a first request to aportable electronic device in communication with the gaming machine, thefirst request representing a request to update a second credit balancestored on the portable electronic device, the second credit balancerepresenting a second amount of credit available on the portableelectronic device, the first request including security authorizationinformation; receiving from the portable electronic device, via thecommunication interface, when it is determined that the securityauthorization information complies with one or more securityauthorization requirements, an indication that the first amount ofcredit has been updated in accordance with the request; and/or updatingthe first credit balance stored in the first memory device in accordancewith the request.

In one or more embodiments, a request (e.g., the first request) mayinclude a request to transfer a designated credit amount from theportable electronic device to the gaming machine and/or a request totransfer a designated credit amount from the gaming machine to theportable electronic device. In one or more embodiments, a request (e.g.,the first request) may be transmitted responsive to a determination thatthe first credit balance has reached a first credit threshold and/orresponsive to a request received from a user of the gaming machine. Insome embodiments, the second processor of the secure transaction devicemay be operable to determine (e.g., using a predetermined auto-transferamount and the first credit threshold) the designated credit amount.

In one or more embodiments, a processor at the secure transaction device(e.g., the second processor) may be operable to determine, in responseto a request to cash out, whether the communication interface is incommunication with the portable electronic device; transfer, in responseto a determination that the communication interface is not incommunication with the portable electronic device, the first creditbalance from the first memory device to the third memory device;transmit a request to the master gaming controller, the requestindicating that the gaming machine should be placed in theout-of-service state; and/or transmit a request to perform ano-card-cash-out operation.

In one or more embodiments, a processor at the secure transaction device(e.g., the second processor) may be operable to determine a firstoffline window for the portable electronic device, the first offlinewindow representing a time period in which the portable electronicdevice may be used for cashless gaming without authenticating with oneor more cashless gaming servers; determine a first on-line use of theportable electronic device, the first on-line use corresponding to amost recent time in which the portable electronic device wasauthenticated with the one or more cashless gaming servers; determine,using the first offline window and the first offline use, whether thefirst offline use is within the first offline window; and/or permit,when the first offline use is within the first offline window, use ofthe portable electronic device without the portable electronic deviceauthenticating with the one or more cashless gaming servers.

In one or more embodiments, a processor at the secure transaction device(e.g., the second processor) may be operable to receive from theportable electronic device, via the communication interface,identification information associated with the portable electronicdevice; transmit, to a cashless gaming server, a first message includingthe received identification information; receive, from the cashlessgaming server, a second message including an indication that further useof the portable electronic device has been at least partially blocked;and/or output a notification that further use of the portable electronicdevice has been blocked.

BRIEF DESCRIPTION OF THE DRAWINGS

The included drawings are for illustrative purposes and serve only toprovide examples of possible structures and process steps for thedisclosed inventive systems and methods for providing game services toremote clients. These drawings in no way limit any changes in form anddetail that may be made to the invention by one skilled in the artwithout departing from the spirit and scope of the invention.

FIG. 1 shows a block diagram 100 illustrating a system for performingsmart card initialization and utilization, constructed in accordancewith one embodiment of the present invention.

FIG. 2 shows a block diagram 200 illustrating an unregistered playersmart card, constructed in accordance with one embodiment of the presentinvention.

FIG. 3 shows a block diagram 300 illustrating a registered player smartcard, constructed in accordance with one embodiment of the presentinvention.

FIG. 4 shows a block diagram 400 illustrating a smart card for use in acashless gaming device, constructed in accordance with one embodiment ofthe present invention.

FIG. 5 shows a method 500 for retrieving a smart card parameter value,performed in accordance with one embodiment of the present invention.

FIG. 6 shows a method 600 for updating a smart card parameter value,performed in accordance with one embodiment of the present invention.

FIG. 7 shows a method 700 for manually transferring credit to or from asmart card, performed in accordance with one embodiment of the presentinvention.

FIG. 8 shows a method 800 for automatically transferring credit to orfrom a smart card, performed in accordance with one embodiment of thepresent invention.

FIG. 9 shows a method 900 for cashing out a smart card, performed inaccordance with one embodiment of the present invention.

FIG. 10 shows a method 1000 for protecting smart card access, performedin accordance with one embodiment of the present invention.

FIG. 11 shows a method 1100 for validating offline use of a smart card,performed in accordance with one embodiment of the present invention.

FIG. 12 shows a method 1200 for transmitting a notification regarding ablocked smart card, performed in accordance with one embodiment of thepresent invention.

FIG. 13 shows a method 1300 for cashing out a missing smart card,performed in accordance with one embodiment of the present invention.

FIG. 14 shows a perspective view of a gaming machine 2, constructed inaccordance with one embodiment of the present invention.

FIG. 15 shows a block diagram illustrating components of a gaming system1500, which may be used for implementing one or more embodiments of thepresent invention.

FIG. 16 shows a server-based gaming network, which may be used forimplementing one or more embodiments of the present invention.

DETAILED DESCRIPTION

Exemplary applications of systems and methods according to the presentinvention are described in this section. These examples are beingprovided solely to add context and aid in the understanding of thepresent invention. It will thus be apparent to one skilled in the artthat the invention may be practiced without some or all of thesespecific details. In other instances, well known process steps have notbeen described in detail in order to avoid unnecessarily obscuring thepresent invention. Other applications are possible, such that thefollowing example should not be taken as definitive or limiting eitherin scope or setting.

In the following detailed description, references are made to theaccompanying drawings, which form a part of the description and in whichare shown, by way of illustration, specific embodiments of the presentinvention. Although these embodiments are described in sufficient detailto enable one skilled in the art to practice the invention, it isunderstood that these examples are not limiting, such that otherembodiments may be used and changes may be made without departing fromthe spirit and scope of the invention.

Although the present invention is directed primarily to gaming machinesand systems, it is worth noting that some of the apparatuses, systemsand methods disclosed herein might be adaptable for use in other typesof devices, systems or environments, as applicable, such that their useis not restricted exclusively to gaming machines and contexts. Suchother adaptations may become readily apparent upon review of theinventive apparatuses, systems and methods illustrated and discussedherein.

In the following figures, method and apparatus applicable to variousgaming system configurations and their associated components aredescribed. The gaming systems may comprise a network infrastructure forenabling one or more hosts to communicate with gaming machines. Thegaming machines may be operable to provide wagering on a game of chance.A plurality of gaming devices, such as bill/ticket validators, printers,mechanical displays, video displays, coin hoppers, light panels, inputbuttons, touch screens, key pads, card readers, audio output devices,etc., may be coupled to the gaming machine. The gaming devices may becontrolled by a master gaming controller executing authenticatedsoftware to provide a gaming interface for a game play experience on thegaming machine.

In one or more embodiments of the present disclosure, a smart cardincludes one or more programs (e.g., Java applets), which may allow bothflexibility and control over the functions of the card as well as theinformation stored thereon. According to conventional techniques (e.g.,in the Gemplus model), a credit balance is a stored value on the smartcard, and an external system, such as a card reader, determines whetherto alter the stored balance values to complete a transaction. A Gempluscard may determine whether a request to alter a stored balance isproperly encrypted, but it does not determine whether the requester hasauthorization to make such a request. In contrast, one or moreembodiments of the present disclosure include a smart card with aprogram residing on the card itself (e.g., a Java applet) that mayverify authorization to perform the transactions. Thus, in one or moreembodiments, an external system requests the card itself to perform atransaction, and only the program on the smart card is permitted toalter the stored credit balance value.

In one or more embodiments, running a verification application on thecard itself instead of a different device eliminates the weak link inthe security, described above. One reason for the increased security isthat when using conventional techniques (e.g., the Gemplus model), itmay be possible to physically intercept communications passing betweenthe card and the system operating on data stored on the card. Thisinterception often occurs at the card read/write interface of the cardreader. However, when embodiments disclosed herein are implemented, theoperations of an application reading and/or updating the stored dataoften cannot be observed, and communications between the application andthe data cannot be intercepted, because the application that operates onthe data may be embedded within the card itself.

Another reason for the increased security is that in one or moreembodiments, the smart card itself verifies whether a requester haspermission to make a request to perform a transaction, and thosetransactions may later be verified before allowing credit stored on thecard to be given to a user as cash. This chain of trust providesincreased security, as well as allowing expanded capabilities. Forexample, the ability to add value to a smart card need not be limited toa few trusted systems, but rather can extend to various devices in acashless transaction system that can at least periodically communicatewith a cashless server or host systems. As another example, devices maycommunicate with a smart card using public key encryption, so theprivate key associated with the smart card is not known to otherdevices. Since different smart cards may have different private keys,the discovery of a cryptographic key associated with one smart card willnot compromise use of other smart cards.

In addition, one or more embodiments of the present disclosure are notlimited to proprietary smart card hardware or memory sizes. Thus, thecosts for each smart card according to the techniques disclosed hereinmay be significantly reduced as compared to traditional techniques.Further, smart cards need not be limited to a three byte purse.

In one or more embodiments, changing a value or configuration parameteron a smart card may include one or more of the following operations: asystem may read one or more parameter(s) stored on a smart card, anapplication on the smart card (e.g., a Patron Management module and/orapplet) may call a function on the application to make a change, theapplication may validate one or more permissions and/or rules, theapplication may make one or more changes to the card, a player mayspecify an amount of money to move to and/or from the card, and/or theappropriate money may be moved to an Electronic Gaming Machine (EGM)when the card is inserted into the EGM and after checking one or moreconfiguration values and/or performing one or more security validations,etc.

In one or more embodiments, by having an application running on thecard, rules may be embedded within the card to perform specificoperations. For example, an application may run on the card thatautomatically triggers a transaction which seeks to replenish funds whena given balance falls below a specified threshold. Such an applicationmay include one or more of the following operations: a system may readone or more parameter(s) stored on a smart card; an application on thesmart card (e.g., a Patron Management module and/or applet) may call afunction on the application to make a change; the application mayvalidate one or more permissions and/or rules; the application may makeone or more change to the card; a player may specify a credit thresholdbalance that may trigger an automatic transfer; and/or the appropriateamount of cash and/or credit may be moved when the card is inserted intoan EGM, when the configuration value is checked, after one or morecredit balances on the EGM are below the specified balance threshold,and/or after performing one or more security validations.

In one or more embodiments, running one or more applications on a smartcard may guard against attempts by unauthorized individuals to access anaccount. For example, one or more applications on a smart card mayperform one or more of the following operations: attempt to validatesecurity if a connection is made to the card; update a record of invalidaccess attempts if the attempt to validate security is unsuccessful;compare the record of invalid access attempts against a pre-definedlimit; make the cashless gaming system aware of one or more illegalaccess attempts; and/or render the card useless if the number of invalidaccess attempts exceeds the pre-defined limit. In one or moreembodiments, information can be retrieved from a smart card but theapplications can no longer change any information once the smart card isrendered useless.

In one or more embodiments, techniques disclosed herein may permitcashing out even when a smart card is not in communication with a gamingmachine (i.e. no-card cashout). Such techniques may include one or moreof the following operations: receiving a request to cash out;determining whether a valid smart card is inserted; transferring creditand/or cash to the card if a valid smart card is present; transferringmoney from the EGM (e.g., to a Slot Machine Interface Board (SMIB)) if avalid smart card is not present; holding the cash and/or credit innon-volatile memory (e.g., in the SMIB); putting the EGM out of service;sending a notification of a no card cash out; receiving a valid smartcard (e.g., a new card brought by a casino attendant); checking securityand/or validating the smart card; moving cash and/or credit to thereceived smart card; putting the EGM back into service.

Thus, in one or more embodiments, the present disclosure describestechniques that may offer a more secure and flexible smart card designthan currently exists. It should be noted that although the sometechniques may be described in reference to wager-based gaming in acasino environment, these techniques are not limited to gaming but maybe applicable to any or all applications and/or industries involvingsmart cards. Even in the gaming context, one or more techniquesdescribed herein may be used to facilitate other cashless transactionsin a casino environment, such as payment for meals, hotel rooms, orother gaming-related expenditures.

Specific details related to techniques for smart card operations and/orcashless gaming in a gaming environment are discussed in U.S. Pat. No.6,852,031, “EZ Pay Smart Card and Tickets System,” by Richard Rowe,filed on Nov. 22, 2000, and U.S. Pat. No. 5,902,983, “Preset AmountElectronic Funds Transfer System for Gaming Machines,” by Crevelt etal., filed on Apr. 29, 1996, both of which are hereby incorporated byreference for all purposes.

FIG. 1 shows a block diagram illustrating cashless gaming system 100,which includes system components associated with smart cardinitialization and/or utilization. According to various embodiments,cashless gaming system 100 may be operable to perform one or moreoperations relating to cashless gaming, such as one or more operationsdescribed herein with reference to FIGS. 5-13. In one or moreembodiments, cashless gaming system 100 may be operable to perform oneor more operations related to security validation and/or verificationprocedures, such as those discussed in U.S. patent application Ser. No.11/967,916, which has been incorporated by reference.

Cashless gaming system 100 includes gaming apparatus 104. In theembodiment of FIG. 1, gaming apparatus 104 is a gaming machine.Additional details regarding gaming machines are discussed herein, andspecifically with respect to FIG. 14. However, according to variousembodiments, different types of gaming apparatuses may include one ormore components related to cashless gaming. For example, in differentembodiments gaming apparatus 104 may instead be a bank of gamingmachines, a kiosk, a cashier's terminal, a patron management terminal, acard initialization terminal, or one or more other devices.

Gaming apparatus 104 includes a slot machine interface board (SMIB) 108.An example of a SMIB according to one or more embodiments is the BonusEngine® available from IGT of Reno, Nev. However, it should be notedthat although gaming machine 104 includes a SMIB, differentimplementations may include one or more different control componentsconfigured to perform similar operations as SMIB 108. For example, ifgaming apparatus 104 were a kiosk or a patron management system, ratherthan a gaming machine, a different device may be used in addition to orinstead of a SMIB. In some embodiments, a patron management system orcashier client may include a device (e.g., an Omnikey 3821 device,available from HID of Walluf, Germany) for reading a smart card in acredit card form factor. One or more systems with an STM device mayinclude a device (e.g., an Omnikey 3121 device, available from HID) forreading a smart card in a SIM card form factor.

SMIB 108 includes CPU 140 and memory 144. The SMIB is in communicationwith other components in the gaming apparatus 104, such as a card reader112, a user input device 116, and a display 120. In one or moreembodiments, the SMIB may communicate with these devices, and/or otherdevices not illustrated in FIG. 1, via one or more serial links.However, according to different embodiments, one or more different typesof communication links may be used. In one or more embodiments, the SMIB108 may communication with one or more remote devices, such as hostsystems 124, via a communication link 128. In one or more embodiments,communication link 128 is a network link in a gaming network. Additionaldetails related to gaming networks are discussed throughout thespecification, and particularly with respect to FIGS. 15 and 16. In oneor more embodiments, the communication link 128 may include one or moreof an Internet link, a satellite link, a wireless link, etc.

In one or more embodiments, the SMIB may be configured or designed tocontrol one or more components in the gaming apparatus, such as the cardreader 112, the user input device 116, and/or the display 120. Inaddition, or alternately, the SMIB may be operable to communicate withone or more different components at the gaming apparatus not illustratedin FIG. 1. For example, the SMIB 108 may communicate with one or morecomponents of the gaming machine, such as a master gaming controller, adisplay device, a service window, etc. As another example, a SMIB, STM,and/or other component associated with the cashless gaming system maycommunicate with one or more different types of devices or interfaces,such as a motherboard, a controller, a network interface, a servicewindow, a kiosk (e.g., a system having a ticketing interface), a displaydevice (e.g., a vacuum fluorescent display, a NexGen or sbNexGenavailable from IGT, etc.), or any other type of device.

Some embodiments of the cashless gaming system may be configured for usein systems that are not under the control of the casino. One such usemay be a point-of-sale interface in which a smart card reader and STM isinstalled in one or more stores, restaurants, hotel facilities (e.g.,service desks, cafes, gift shops), or other commercial locations. Such aconfiguration may allow a player to use the smart card to pay fornon-gaming goods or services. A smart card configured for use in such asystem may include more than one purse (i.e. credit balance). The use ofmore than one purse may allow a casino to provide different types ofcredit on a smart card (e.g., gambling credits, cash, promotionaldollars, bonus points, loyalty points, etc.) and/or avoid co-minglinggaming and non-gaming funds (e.g., for regulatory compliance).

As stated herein, the SMIB includes memory 144. In one or moreembodiments, memory 144 may include program instructions for CPU 140,such as program instructions relating to performing one or moreoperations for cashless gaming. In one or more embodiments, memory 144may store one or more parameter values related to cashless gaming. Forexample, memory 144 may store a credit balance for transfer betweengaming apparatus 108 and a smart card, such as a smart card incommunication with smart card slot 132. In one or more embodiments,memory 144 is non-volatile memory. Thus, in the event of a system reset,a credit value stored on memory 144 may be maintained in event of asystem failure, loss of power, and/or reset.

In some embodiments, the SMIB may function according to a TransactionComplete model in which activity is not recorded to a transaction recorduntil the transaction is completed on the smart card. Thus, if atransaction is interrupted before it can be completed (e.g., by powerloss), the partially completed transaction may not be recorded in thecashless gaming system. The Transaction Complete model may thus preventcash from being lost (e.g., transferred from an STM but not recorded ona smart card) or duplicated (e.g., transferred to a smart card but notremoved from an STM).

A card reader 112 is illustrated in FIG. 1. Card reader 112 may beoperable to communicate with slot machine interface board 108. Accordingto different embodiments, the card reader 112 may include one or morecommunication interfaces for communicating with one or more portableelectronic devices. For example, the card reader 112 includes a smartcard slot 132 and a SIM card slot 136. However, according to differentembodiments various numbers, types, and/or combinations of communicationinterfaces may be used.

In FIG. 1, reference numeral 132 denotes a smart card slot. Smart cardslot 132 may be operable to communicate with a portable electronicdevice, such as a smart card. In one or more embodiments, a smart cardslot may be a physical slot into which a smart card may be inserted.Alternately, or additionally, the smart card slot 132 may be a wirelesscommunication interface configured to communicate wirelessly with asmart card and/or a different type of portable electronic device.

In one or more embodiments, the card reader 112 may communicate with oneor more portable electronic devices operable to store a credit balancefor cashless gaming. For example, the card reader 112 may communicatewith a smart card via smart card slot 132. In such embodiments, smartcard slot 132 may be positioned so as to be accessible to a user ofgaming apparatus 104. For example, smart card slot 132 may include aphysical slot on the external surface on the gaming apparatus 104.

Reference numeral 136 denotes a SIM card slot. In one or moreembodiments, SIM card slot 136 may be configured to communicate with aportable electronic device, such as a smart card designed or configuredin accordance with one or more of the Subscriber Identity Model (SIM)card form factors. As with the smart card slot 132, the SIM card slot136 may be a physical slot, a wireless communication interfaceconfigured to communicate wirelessly with a SIM card or other portableelectronic device, or any other type of communication interface.

In one or more embodiments, the card reader 112 may communicate with oneor more portable electronic devices operable to facilitatecommunications/security functions, such as a Secure Transaction Module(STM) card. For example, the card reader 112 may communicate with a STMcard embodied in a SIM card format via the SIM card slot 136. In one ormore embodiments, the STM card may perform one or more encryption,decryption, and/or security validation operations associated withcommunications between a smart card and the gaming apparatus 104. Forexample, the STM card may encrypt communications transmitted from theSMIB 108 to a smart card. As another example, the STM card may decryptcommunications transmitted from the smart card to the gaming apparatus104.

In one or more embodiments, using an STM card for securingcommunications between the gaming apparatus 104 and a smart card mayhave one or more advantages. For example, it may be easy to add and/orremove the STM card from the gaming apparatus 104. Thus, the STM cardcould be easily replaced with a different STM card. As another example,security operations may be performed independent of other functions ofthe gaming machine and/or SMIB. As yet another example, the STM card maybe preconfigured to perform one or more operations specific to one ormore specific types of gaming apparatuses. Additional details regardingSTM cards are discussed in relation to FIG. 4.

In one or more embodiments (e.g., one or more embodiments in which cardreader 112 is operable to communicate with a STM card via the SIM cardslot 136), the gaming apparatus 104 may include one or more securityfeatures for protecting access to SIM card slot 136. In one or moreembodiments, the card reader 112 may be configured or designed such thatSIM card slot 136 is hidden from a user during the normal course ofoperation of gaming machine 104. For example, card reader 112 may beconfigured or designed such that in order to add or remove a card fromSIM card slot 136, the door of the gaming machine must be opened. Asanother example, unauthorized access to the SIM card slot 136 mayrequire one or more digital and/or physical keys, trigger an audibleand/or silent alarm, etc.

Although an embodiment of the card reader 112 illustrated in FIG. 1 isdescribed as communicating with an STM card via SIM card slot 136 andcommunicating with a player's smart card via smart card slot 132,different embodiments may include different configurations. For example,according to different embodiments, either or both the player's smartcard and the STM card may be embodied in one or more smart card formats,SIM card formats, or any other type of format for a portable electronicdevice. As another example, in one or more embodiments, an STM card maybe physically coupled with a gaming apparatus such that the cardcommunicates with one or more components of the gaming apparatus withoutcommunicating via a removable slot. For example, the STM card may be ahardware and/or software component coupled with one or more componentsof the gaming apparatus and configured via an interface on the gamingapparatus (e.g., over a network, via a user interface, using a remotedevice, etc.).

In FIG. 1, reference numeral 116 denotes a user input device. Accordingto various embodiments, the user input device 116 may be any inputdevice configured or designed to receive user input. For example, theuser input device 116 may be a touch pad, a touch screen, a keypad, akeyboard, a button panel, etc.

In one or more embodiments, the user input device may receive user inputrelated to cashless gaming. For example, the user input device mayreceive a request to move cash and/or credit between the gamingapparatus and a portable electronic device in communication with thecard reader 112 (e.g., a smart card in communication with smart cardslot 132. As another example, the user input device may receive arequest to update one or more parameter values on a smart card incommunication with the card reader 112 (e.g., an updated player name,preferred language, auto-transfer threshold value, auto-transfer amount,etc.).

Reference numeral 120 denotes a display. According to variousembodiments, different types of displays may be used. For example, thedisplay 120 may be an LCD, an LED display, a plasma display, aseven-segment display, etc. In one or more embodiments, user inputdevice 116 and display 120 may be part of the same device (e.g., a touchscreen display).

The display 120 may be operable to display information related tocashless gaming. For example, the display 120 may show one or moreparameter values stored on a portable electronic device in communicationwith card reader 112, such as one or more parameter values (e.g., playernames, preferred languages, auto-transfer amounts, auto-transferthresholds, credit balances, etc.) stored on a smart card incommunication with smart card slot 132. In one or more embodiments, thedisplay 120 may show options for modifying one or more values on aportable electronic device in communication with smart card slot 132(e.g., a list of possible preferred languages, a selection of approvedauto-transfer threshold values, a selection of approved auto-transferamounts, etc.).

In FIG. 1, reference numeral 124 denotes host systems. Host systems 124may include one or more servers related to cashless gaming. Slot machineinterface board 108 and host systems 124 may be configured tocommunicate via one or more network links, such as network link 128. Inone or more embodiments, network link 128 may be a network link in agaming network at a casino. Further details of a gaming network will bediscussed in relation to FIG. 17. However, according to differentembodiments, network link 128 may include one or more communicationlinks in a public network, such as the internet.

Examples of the types of portable electronic devices that maycommunicate with one or more components of the gaming apparatus 104 viathe smart card reader 132 and/or SIM card slot 136 are smart cards 200,300, and 400 shown in FIGS. 2, 3 and 4. Smart cards 200, 300, and 400are portable electronic devices that each have memory and one or moreprocessors. In addition, smart cards 200, 300, and 400 are each operableto communicate with one or more other devices in a cashless gamingsystem and/or casino environment.

Smart cards 200, 300, and 400 are Java smart cards designed to executeone or more programs, applications, and/or applets written in the Javaprogramming language. However, according to different embodiments,various types of programming languages may be used for variouscomponents in the cashless gaming system, such as C, C++, C#, .Net, etc.In addition, according to various embodiments one or more of smart cards200, 300, and/or 400 may be embodied in various shapes or form factors.For example, a smart card may be embodied in a SIM card, a credit cardsized smart card, or any other type of portable electronic device.

FIG. 2 shows a smart card 200 that is configured or designed for use byone or more players in a casino environment, in accordance with oneembodiment of the present invention. Smart card 200 is an unregisteredsmart card (e.g., a “day use” smart card) that does not include personalidentification information (e.g., name, identification number, and/or isnot tied to a particular user.

In one or more embodiments, the unregistered smart card 200 is operableto communicate with one or more other devices in a gaming network bybeing placed in a smart card slot, such as the smart card slot 132.However, in different embodiments, smart cards may communicate using oneor more different techniques, for example communication via a SIM cardslot (e.g., SIM card slot 136) and/or wireless communication.

Unregistered smart card 200 may include one or more hardware and/orsoftware modules for performing functions related to cashless gaming.Each module may include data and/or program instructions. In one or moreembodiments, one or more modules may be preloaded on the unregisteredsmart card 200 when the smart card is constructed. In addition, oralternately, one or more modules may be configured and/or loaded on theunregistered smart card 200 via a device in a casino environment such asa gaming machine. Unregistered smart card 200 includes a card manager204, a security module 208, and a wallet module 212.

The card manager 204 is a hardware and/or software module that includesdata and/or program instructions for accessing one or more features onthe unregistered smart card 200. In one or more embodiments, the cardmanager 204 comes preconfigured on new smart cards. However, indifferent embodiments, the card manager 204 may be added and/orconfigured by one or more devices in a cashless gaming system.

The card manager 204 may include identification information specific tothe individual unregistered smart card 200, such as a smart card serialnumber. In one or more embodiments, the smart card manager 204 mayinclude one or more cryptographic access keys and/or cryptograms foraccessing the unregistered smart card 200. For example, card manager 204may include standard keys that are loaded on the smart card duringconstruction.

In one or more embodiments, at least some information stored in smartcard manager 204 may be unalterable. For example, it may be impossibleto alter the smart card serial number and/or one or more cryptographicaccess keys without rendering the smart card inoperable. Alternately, oradditionally, it may be possible to alter one or more of the values(e.g., with appropriate security verification).

According to various embodiments, card manager 204 may permit adding,removing and/or configuring other modules on the smart card. Forexample, card manager 204 may permit adding, removing, and/orconfiguring security module 208 and/or wallet module 212.

The security module 208 is a hardware and/or software module thatincludes data and/or program instructions for performing one or morefunctions related to access control and/or security verification. Forexample, the unregistered smart card 200 may receive one or morerequests to read and/or update one or more values stored in the memoryof the unregistered smart card 200. In one or more embodiments, some orall requests to access and/or update values must be validated by thesecurity module 208 before being performed by one or more modules on thesmart card.

Thus, in one or more embodiments, the security module 208 may includeone or more pieces of information related to authenticating request toaccess the unregistered smart card 200. For example, the security module208 may include a Personal Identification Number (PIN) and/or one morecryptographic keys for enabling secure communication. In addition, thesecurity module 208 may store information relating to one or moreprevious transactions, previous authorizations of the smart card,transaction counts, serial numbers (e.g., a unique serial numberassociated with the smart card), etc. The different values stored on thesmart card (e.g., in the security module) may alternately beuser-configurable, configurable by the casino, or not configurable(e.g., a card serial number). In some embodiments, values configurableby a casino may be updated when a card is accessed at an STM device. Inthis way, a casino may push out new parameter values to be stored onsmart cards upon their next use.

In addition, in one or more embodiments, the security module 208 mayinclude program instructions for authenticating one or more requests toaccess the unregistered smart card 200. For example, the security module208 may include program instructions for performing one or morefunctions related to secure cryptographic communications. In addition,the security module 208 may include program instructions for verifyingthat the sender of a request to access one or more values on theunregistered smart card 200 has the appropriate security permissions forperforming said access.

The wallet module 212 is a hardware and/or software module that includesdata and/or program instructions for performing one or more operationsrelated to storing and/or transferring cash and/or credit values forcashless gaming. For example, the wallet module may be configured tostore one or more credit balances. A credit balance may be an amount ofcredit and/or cash available for use in gambling in a casinoenvironment. The wallet module 212 may also include program instructionsfor one or more programs related to adding and/or removing credit fromthe wallet module 212.

In one or more embodiments, the wallet module 212 may be configured ordesigned to store one or more parameter values related to adding and/orremoving credits stored on the wallet module. For example, the walletmodule may store one or more auto-transfer threshold values. Anauto-transfer threshold value may be used to determine when toautomatically transfer additional credit from the smart card (e.g.,credit stored in the wallet module 212) to a gaming machine. When theunregistered smart card 200 is in communication with the gaming machine,a determination may be made as to whether one or more credit balances onthe gaming machine (e.g., for playing a game of chance) has droppedbelow the auto-transfer threshold value stored on the wallet module. Ifthe credit balance on the gaming machine is less than the auto-transferthreshold value on the wallet module, additional credit may be movedfrom the smart card to the gaming machine.

As another example, the wallet module 212 may be configured to store oneor more auto-transfer amounts. When credit is automatically transferredfrom the wallet module 212 to a gaming machine, the amount of credit maybe determined in accordance with the auto-transfer threshold value.According to different embodiments, different techniques for determiningthe amount of credit may be used. For example, the amount of credittransferred from the smart card to the gaming machine may be determinedso as to raise the balance on the gaming machine to the sum of theauto-transfer threshold value and the auto-transfer threshold amount.Alternately, the amount of credit transferred from the smart card to thegaming machine may be substantially equal to the auto-transfer thresholdamount.

According to various embodiments, various techniques may be used to addand/or modify one or more parameter values stored on the unregisteredsmart card 200. In one or more embodiments, one or more parameter valuesmay be determined and/or stored on the smart card upon initialization ofthe card (e.g., at an initialization terminal), at a cashier's terminal,at a kiosk, at a patron management terminal, at a gaming machine, etc.In one or more embodiments, permission to change one or more valuesstored on the smart card may be limited to one or more specific types ofgaming apparatuses. For example, a casino may require supervision bycasino personnel in order to change the auto-transfer threshold valueand/or auto-transfer amount, since setting these values too low may insome instances cause excessive credit transfers during game play and/orexcessive wear and tear on the card. Alternately, a casino may provide arange of preapproved values and/or permit card users to change one ormore values without supervision (e.g., at a gaming machine, kiosk,etc.).

In one or more embodiments, a casino may restrict the values that may beused as the auto-transfer threshold value and/or auto-transfer amount soas to reduce excessive wear at the smart card and/or to imposeoperational limits on credit transfers. For example, a casino may imposea maximum auto-transfer amount of $10,000 in a High Limit gaming roomand a maximum auto-transfer amount of $100 on the main floor. Suchgame-specific or area-specific restrictions may prevent a player fromtransferring an excessive amount of credit to a low-denomination gamingmachine (e.g., $5,000 transferred to a $0.25 slot machine). Thus, evenif a player's auto-transfer amount is set at $200, the actual valuetransferred to the gaming machine on the casino floor would be limitedto $100 in this example. In this way, the casino can balance playerpreferences with operational concerns such as security and riskmanagement.

In some embodiments, limits on auto-transfer parameters may be imposedfor individual games, for groups of games, for specific smart cards(e.g., for individual players), for groups of players, for differentcasino properties, etc. Furthermore, the types of limits imposed mayinclude threshold values (e.g., as discussed in the precedingparagraph), percentage-based restrictions (e.g., an auto-transfer valuelimited to 75% of the credit balance), or other types of limitations. Insome embodiments, more than one limit on a smart card parameter may beimposed

FIG. 3 shows a block diagram 300 illustrating a registered player smartcard, constructed in accordance with one embodiment of the presentinvention. Smart card 300 is a registered smart card that includespersonal identification information and/or other information (e.g.,name, identification number, etc.) associated with one or more specificusers.

In one or more embodiments, the registered smart card 300 may beoperable to communicate with one or more other devices in a gamingnetwork by being placed in a smart card slot, such as the smart cardslot 132. However, in different embodiments, the registered smart card300 may communicate using one or more different techniques, for examplecommunication via a SIM card slot (e.g., SIM card slot 136) and/orwireless communication.

The registered smart card 300 may include one or more hardware and/orsoftware modules for performing functions related to cashless gaming.Each module may include data and/or program instructions. In one or moreembodiments, one or more modules may be preloaded on the registeredsmart card 300 when the smart card is constructed. In addition, oralternately, one or more modules may be configured and/or loaded on theregistered smart card 300 via a device in a casino environment such as agaming machine.

In may respects, the registered smart card 300 may be substantiallysimilar to the unregistered smart card 200 shown in FIG. 2. For example,the registered smart card 300 includes a card manager 304, a securitymodule 308, and a wallet module 312 that may be substantially similar tothe corresponding modules illustrated in FIG. 2.

In some embodiments, the wallet module 312 may be configured to storeand access multiple purses or credit balances. Furthermore, the variouscredit balances may be denominated in cash, casino credits, points, orany other units. Different credit balances that may be stored on thesmart card may include, but are not limited to, one or more of thefollowing: a gambling balance, a non-gambling balance, promotionaldollars, bonus points, loyalty points, player tracking points, etc.

In some embodiments, access to different purses may be limited tospecific STMs, or STMs in particular types of machines. That is, onlycertain STMs may possess the security permissions necessary to accesspurses. For example, access to gambling-related purses may be limited togaming machines, cashier terminals, etc. Access to promotional pursesmay be limited to patron management terminals or systems where awardsmay be redeemed. Access to non-gambling cash may be limited topoint-of-sale interfaces (e.g., in shops or restaurants) and cashier'sterminals.

Enforcing these types of access controls may provide casinos with theability to facilitate flexible smart card use while retaining controlover access to disparate purses by different systems and entities.Further, enforcing separation of funds may assist in ensuring thatembodiments of the cashless gaming system comply with regulatoryrequirements related to separation of gambling and non-gambling funds.

In some embodiments, access to different purses may be controlled bydifferent PINs. For example, access to one or more gambling-relatedpurses may require a first PIN, while access to one or more non-gamblingpurses may require a second PIN. Separate access controls may allow, forinstance, a player to lend a smart card to a different person (e.g., aminor) for limited uses (e.g., non-gambling uses, restaurant purchases,shop purchases, hotel purchases, redemption of awards, etc.).

In addition to the components included in the unregistered smart card200, registered smart card 300 includes a patron management module 316.The patron management module 316 is a hardware and/or software modulethat includes data and/or program instructions for performing one ormore user-specific operations. For example, the patron management module316 may store information related to one or more names, ranks, playeridentification numbers, PINs, preferred languages, and/or otherinformation specific to one or more users. As another example, thepatron management module 316 may include program instructions associatedwith verifying a user's identity and/or performing one or more playertracking operations.

The patron management module may also be used to store and/or adjust oneor more non-cash values related to loyalty awards, extra credits,offline bonuses, etc. In some embodiments, if a player is credited witha free meal or free game plays, those values may be stored on the smartcard by the patron management module. Then, the player may redeem thecredit or award by presenting the smart card at the appropriate time.

According to various embodiments, various techniques may be used to addand/or modify one or more parameter values stored on the registeredsmart card 300. In one or more embodiments, these techniques may besimilar to those discussed with respect to unregistered smart card 200.However, in one or more embodiments, registered smart card 300 may betreated differently than unregistered smart card 200. For example, acasino may not require authentication steps in order to change valuesstored on the unregistered smart card 200 since the unregistered smartcard 200 is not tied to a specific user. In contrast, since registeredsmart card 300 is tied to a specific user, a casino may require that theuser provide identification information (e.g., an ID card, biometricidentification information, etc.) and/or perform one or more electronicauthentication operations in order to modify one or more values storedon the smart card. As another example, a user associated with registeredsmart card 300 who wishes to change one or more values stored on aregistered card may need to provide identification information to casinopersonnel (e.g., at a kiosk, patron management terminal, etc.).

FIG. 4 shows a block diagram 400 illustrating a smart card for use in acashless gaming device, constructed in accordance with one embodiment ofthe present invention. The smart card shown in FIG. 4 is configured ordesigned for use as an Secure Transaction Module (STM) card. The STMcard 400 may be configured and/or designed for use in performing and/orfacilitating one or more security validation and/or communicationoperations associated with secure transactions at a gaming apparatus.

In one or more embodiments, the STM card 400 may be operable tocommunicate with one or more other devices in a gaming network by beingplaced in a SIM card slot, such as the SIM card slot 136. However, indifferent embodiments, the STM card 400 may communicate using one ormore different techniques, for example communication via a smart cardslot (e.g., the smart card slot 132) and/or wireless communication.

The STM card 400 may include one or more hardware and/or softwaremodules for performing functions related to cashless gaming. Each modulemay include data and/or program instructions. In one or moreembodiments, one or more modules may be preloaded on the STM card 400when the smart card is constructed. In addition, or alternately, one ormore modules may be configured and/or loaded on the STM card 400 via adevice in a casino environment such as a gaming machine.

In many respects, the STM card 400 may be substantially similar to theunregistered smart card 200 shown in FIG. 2 and the registered smartcard 300 shown in FIG. 3. For example, the STM card 400 includes a cardmanager 404 and a security module 408 that may be substantially similarto the corresponding modules illustrated in FIGS. 2 and 3. However,since the STM card 400 is not issued to a player, it may not need toinclude, for example, a wallet module and/or patron management module.

Another difference between the STM card 400 and the smart cards 200 and300 shown in FIGS. 2 and 3 is that the STM card 400 includes a SecureTransaction Manager (STM) module 412. The STM module 412 is a hardwareand/or software module that includes data and/or program instructionsfor performing one or more operations related to securely facilitatingcashless gaming transactions (e.g., with a smart card). In one or moreembodiments, the STM module 412 may be operable to communicate with asmart card (e.g., via the card reader 112). Additionally, oralternately, the STM module 412 may be operable to communicate with oneor more servers in a cashless gaming system (e.g., the host systems124).

In one or more embodiments, the STM module 412 includes one or morecryptographic keys for communication using a secured cryptosystem (e.g.,a public key cryptosystem). In this way, communication between the STMmodule 412 and a smart card (e.g., a smart card in communication withsmart card slot 132) may be encrypted. In addition, or alternately,communication between the STM module 412 and one or more systemcomponents (e.g., SMIB 104) and/or remote servers (e.g., host systems124) may be encrypted. In one or more embodiments, the STM module 412may be registered with one or more remote servers.

Such registration may take place, for example, each time a gamingmachine or cashless gaming terminal is powered up. Alternately, oradditionally, registration may occur during use of the gaming machine orcashless gaming terminal (e.g., at scheduled times, intermittently,etc.). In some embodiments, the registration process may be integratedwith one or more procedures for registering gaming machines, such as theAdvantage Bonus System and/or Easy Pay systems available from IGT.

At certain instances, use of a smart card at a gaming apparatus mayinvolve authenticating the smart card to a remote server, such as acashless gaming server. Such authentication may involve, for example,verifying the authenticity of the smart card (e.g., using one or morecryptographic keys), verifying one or more previous transactionsassociated with the smart card, verifying the identity of the smart carduser, etc.

In one or more embodiments, an authentication attempt may be madeduring, before, and/or after each cashless gaming session and/or otheruse of the smart card. Alternately, an authentication attempt may bemade only upon occasion (e.g., periodically, when triggered, etc.).

However, in some instances, such authentication may be impossible and/orimpracticable. For example, one or more network elements and/or serversmay be temporarily and/or periodically inoperable. As another example,the gaming apparatus at which the card is being used may not enjoycontinuous communication with a cashless gaming server.

Thus, in one or more embodiments, the STM module 412 may include one ormore parameter values associated with one or more offline windows. Anoffline window value may represent, for example, a length of timebetween the last authenticated use of a specific smart card and the timein which it must be authenticated again before it can be used further.In one or more embodiments, the offline window is 24 hours, which meansthat if a given smart card has been authenticated with a remote cashlessgaming server at a particular time (e.g., during use for a cashlessgaming session), that smart card may be used for 24 hours withoutrequiring that the smart card be authenticated again with a remotecashless gaming server. According to various embodiments, the offlinewindow may be any value between 0 hours (e.g., offline use is notpermitted) to several weeks.

The use of an offline window may allow the player to use the smart cardeven if remote authentication of the card is not performed. However, ifit is determined that the previous authenticated use of the smart cardfalls outside of the offline use window, then the gaming apparatus mayrefuse to add and/or retransfer credit from the smart card. Furtherdetails of the use of offline windows are discussed in relation to FIGS.9, 11, and 13.

In one or more embodiments, one or more parameter values stored on theSTM card 400 may be stored upon initialization of the STM card. Forexample, the STM card 400 may store one or more parameters related tooffline windows, cryptographic keys, card value limits for unregisteredsmart cards, etc. Storing one or more parameter values on the STM cardmay allow the casino to exercise control over the cashless gamingsystem, such as providing useful ways to manage risk. For example, acasino may dynamically alter the maximum credit balance that may bestored on unregistered smart cards. If the casino knows that there aremany players using unregistered smart cards, for instance, the casinomay reduce the maximum credit balance that may be stored on unregisteredsmart cards in order to reduce risk (e.g., in the event of systemfailure).

In one or more embodiments, such parameters may not be modified afterthey have been stored on the card. For example, the STM card 400 mayinclude non-volatile memory so as to thwart attempts to tamper with theSTM card 400. However, in different embodiments, it may be possible tomodify one or more parameter values stored on the STM card 400 and/oradd new parameter values. For example, a casino employee may be able toupdate one or more parameter values stored on the STM card 400 byaccessing the STM card 400 via a gaming apparatus (e.g., by providingappropriate credentials, cryptographic keys, security verificationinformation, etc.).

FIGS. 5-13 show methods related to cashless gaming transactions that maybe performed in conjunction with a smart card. According to variousembodiments, one or more of the methods may be performed via one or moregaming apparatuses in communication with a smart card and/or STM. Forexample, one or more methods may be performed via gaming apparatus 104in communication with a smart card via smart card slot 132 and an STMcard via SIM card slot 136. According to various embodiments, one ormore of the methods may be performed at various locations. For example,one or more operations associated with the methods may be performed atcashier terminal, at a patron management terminal, at a kiosk, at agaming machine, etc.

In one or more embodiments, one or more of the methods illustrated inFIGS. 5-13 may be preceded by one or more authentication operations. Forexample, one or more components associated with a gaming apparatus maycommunicate with the smart card and/or STM card to establish a securecommunications session. In one or more embodiments, the smart card andSTM card may exchange public keys used in a public key cryptosystemand/or exchange session keys.

Although the operations illustrated in FIGS. 5-13 are illustrated asoccurring in a particular order, in one or more embodiments one or moremethods may include operations may be performed in a different order. Inaddition, some implementations may include additional operations notillustrated in FIGS. 5-13, and/or some operations may be omitted.

FIG. 5 shows a method 500 for retrieving a parameter value from a smartcard, performed in accordance with one embodiment of the presentinvention. The Retrieve Smart Card Parameter Value Procedure 600 may beused to retrieve one or more parameter values stored on a smart cardwhen the smart card is in communication with a cashless gamingapparatus. For example, a smart card user, casino personnel, and/or aprogram running on a gaming apparatus may make a request to update aparameter value stored on the smart card.

The Retrieve Smart Card Parameter Value Procedure 500 may be performedat various instances and/or upon various triggering events. For example,a smart card user, casino personnel, and/or a program running on agaming apparatus may make a request to retrieve a parameter value storedon the smart card. As another example, one or more operationsillustrated in FIG. 5 may be performed upon card initialization, uponinserting a smart card into a gaming apparatus, etc.

At 504, instructions are transmitted from the cashless gaming apparatusto the smart card to call a function on the smart card to retrieve oneor more parameter values. The requested parameter values may include,for example, one or more credit balances, auto-transfer thresholdvalues, auto-transfer amounts, player names, player ranks, player ID's,smart card serial numbers, PINs, etc. In one or more embodiments, therequest may be cryptographically signed by the STM card before beingtransmitted to the smart card.

At 508, a determination is made as to whether the request to retrieveone or more parameter values satisfies one or more permissions and/orrules. In one or more embodiments, the determination is made at anapplication or software module running on the smart card (e.g., thesecurity module 208). The determination may be made, at least in part,based upon whether the request has been signed and/or encrypted by avalid and/or approved STM card. The determination may involve ahandshaking and/or key exchange process. For example, a key signaturemay be stored in the transaction record on the card and on the STM. Ifthese key signatures match, then the request may be considered valid.

In one or more embodiments, all valid STM cards may have permission toretrieve any value from a smart card. However, in different embodiments,permission to retrieve one or more values from a smart card may belimited to certain types of gaming apparatuses equipped withappropriately configured STM cards. Thus, operation 508 may involvedetermining whether the STM card that transmitted the request toretrieve one or more parameter values has permission to retrieve thosevalues. For example, an STM card associated with a patron managementterminal may not have permission to access values stored in the walletmodule, such as an auto-transfer amount. However, an STM card associatedwith a cashier's terminal may have permission to access one or morevalues stored in the wallet module, such as a credit balance.

At 512, when it is determined that the request to retrieve one or moreparameter values satisfies the permissions and/or rules, the one or moreparameter values are transmitted from the smart card to the gamingmachine. In one or more embodiments, the parameter values aretransmitted as part of a secure communications session between the smartcard and an STM card. Thus, the STM card may decrypt the communicationfrom the smart card that includes the parameter values beforetransmitting the communication and/or the parameter values to adifferent device in the gaming apparatus, such as the SMIB 104.Alternately, or additionally, one or more parameter values may betransmitted in an unencrypted state.

It should be noted that in one or more embodiments, certain requests toretrieve one or more parameter values may not require the use ofoperation 508. For example, a smart card may freely transmit informationsuch as a user's name and/or identification number. In differentembodiments, however, each request to retrieve one or more parametervalues must be validated by the smart card.

FIG. 6 shows a method 600 for updating a smart card parameter value,performed in accordance with one embodiment of the present invention.The Update Smart Card Parameter Value Procedure 600 may be used toupdate one or more parameter values stored on a smart card when thesmart card is in communication with the cashless gaming apparatus. Forexample, a smart card user, casino personnel, and/or a program runningon a gaming apparatus may make a request to update a parameter valuestored on the smart card.

At 604, instructions are transmitted from the cashless gaming apparatusto the smart card to call a function on the smart card to update one ormore parameter values. The parameter values included in the updaterequest may include, for example, one or more credit balances,auto-transfer threshold values, auto-transfer amounts, player names,player ranks, player ID's, smart card serial numbers, PINs, etc.

At 608, a determination is made at an application running on the smartcard as to whether the request to update one or more parameter valuessatisfies one or more permissions and/or rules. In one or moreembodiments, the determination is made by a security module on the smartcard (e.g., the security module 208). The determination may be made, atleast in part, based upon whether the request has been signed and/orencrypted by a valid and/or approved STM card.

According to various embodiments, permission to perform one or moreoperations on a smart card, such as updating a parameter value, may belimited to certain types of gaming apparatuses and/or certain STM cards.Thus, operation 608 may involve determining whether the STM card thattransmitted the request to update one or more parameter values haspermission to update those values.

For example, an STM card associated with a patron management terminalmay not have permission to update one or more parameter values stored inthe wallet module, such as an auto-transfer amount. However, an STM cardassociated with a cashier's terminal may have permission to update oneor more parameter values stored in the wallet module.

As another example, an STM card associated with a gaming machine may bepermitted to update one or more values associated with the wallet module(e.g., auto-transfer amount and/or auto-transfer threshold values) of anunregistered smart card (e.g., smart card 200), since the unregisteredsmart card is not tied to the identity of a specific user. However, thesame STM card may not have permission to update one or more valuesassociated with the wallet module of a registered smart card, since acasino may wish to validate the identity of a player in person beforeallowing such a change.

One reason for enforcing such permissions may be security. For example,permission to transfer funds for purposes of cashing out a smart cardmay be limited to secure devices that are under the control of casinopersonnel.

Another reason for enforcing such permissions may be to ensure thatinappropriate parameter values are not stored to the smart card. Forexample, as is discussed with respect to FIG. 8, one or more devices inthe cashless gaming system may be configured or designed toautomatically transfer credit from a smart card when a credit balance ona gaming machine drops below an auto-transfer threshold value. However,if the difference between the auto-transfer threshold value and theauto-transfer amount is too small, the transfers from the smart card tothe gaming machine may be too frequent, resulting in excessive wear onthe smart card and/or excessive authorization attempts with one or moreremote servers. Thus, limiting permission to update values such as theauto-transfer threshold value and/or auto-transfer threshold amount tocertain STMs (e.g., STMs installed at gaming apparatuses operated bycasino personnel) may ensure that only appropriate parameter values arestored to the smart card. Additionally, or alternately, one or moregaming apparatuses may be configured or designed to automaticallyenforce restrictions on parameter values.

At 612, when it is determined that the request to update one or moreparameter values satisfies the permissions and/or rules, the one or moreparameter values are updated on the smart card. In one or moreembodiments, the smart card may transmit an indication and/orconfirmation that the one or more parameter values were successfullyupdated. In one or more embodiments, the parameter values aretransmitted as part of a secure communications session between the smartcard and an STM card. Thus, the STM card may decrypt the communicationfrom the smart card that includes the update confirmation beforetransmitting the communication and/or an indication that the values weresuccessfully updated to a different device in the gaming apparatus, suchas the SMIB 104. In different embodiments, the smart card may nottransmit an indication and/or confirmation of a successful update. Insuch embodiments, the Retrieve Smart Card Parameter Value Procedure 500shown in FIG. 5 may be used to determine whether one or more parametervalues was successfully updated.

It should be noted that in one or more embodiments, certain requests toupdate one or more parameter values may not require the use of operation608. For example, a smart card may permit a user, casino employee,and/or program running at a gaming apparatus to update low-securityinformation (e.g., a preferred language) without requiring one or moreauthentication and/or request validation operations.

FIG. 7 shows a method 700 for manually transferring credit to or from asmart card, performed in accordance with one embodiment of the presentinvention. The Smart Card Credit Manual Transfer Procedure 700 may beused to transfer credit from a gaming apparatus to a smart card or froma smart card to a gaming apparatus. For example, a smart card manualtransfer procedure may be used at a cashier terminal in order to addcredit to a smart card. The Smart Card Credit Manual Transfer Procedure700 may also be used at a cashier terminal to convert credit stored onthe smart card to cash for providing to a player associated with thesmart card. As another example, the Smart Card Credit Manual TransferProcedure 700 may be used at a gaming machine in order to transfercredit from the gaming machine to the smart card or from the smart cardto the gaming machine.

At 704, a request is received to transfer credit between the smart cardand a gaming system. According to various embodiments, the request maybe received at one or more apparatuses in a cashless gaming system(e.g., a cashier terminal, a gaming machine, etc.).

In some instances, the request to transfer credit may represent arequest to transfer credit stored on the smart card to a gamingapparatus. Such a transfer may be requested, for example, to facilitatecashless gaming on a gaming machine or to award cash to a player basedon the credit stored on the smart card (i.e. “cash out” the smart card).In other instances, the request to transfer credit may represent arequest to transfer credit stored on the gaming apparatus to the smartcard. Such a transfer may be requested, for example, to add additionalfunds to the smart card and/or at the end of a cashless gaming sessionat a gaming machine.

In one or more embodiments, some requests to transfer credit may beperformed by casino personnel and/or may require supervision by casinopersonnel. For example, permission to request to transfer credit from asmart card to a cashier terminal for the purpose of cashing out a smartcard may be limited to designated casino employees, such as cashiers. Inaddition, or alternately, one or more additional operations may berequired when cashing out a smart card. Further details related tocashing out a smart card are discussed in relation to FIGS. 9 and 13.

In one or more embodiments, some or all requests to transfer credit mayrequire a user to provide identification and/or security verificationinformation, such as a PIN. For example, a player may be required toprovide a PIN number, produce an ID card or provide other forms ofidentification information. As another example, a casino employee makinga request to transfer credit and/or assisting a user in making such arequest may be required to provide a PIN and/or other verificationinformation.

At 708, instructions are transmitted to call a function on the smartcard to transfer credit between the smart card and the gaming apparatus.In one or more embodiments, the instructions are transmitted from acomponent associated with the gaming apparatus, such as the SMIB 104,via an STM card associated with the gaming apparatus (e.g., an STM cardin communication with SIM card slot 136).

At 712, a determination is made at an application running on the smartcard as to whether the request to transfer credit satisfies one or morepermissions and/or rules. In one or more embodiments, the determinationis made by a security module on the smart card (e.g., the securitymodule 208). The determination may be made, at least in part, based uponwhether the request has been signed and/or encrypted by a valid and/orapproved STM card.

According to various embodiments, permission to transfer credit to orfrom the smart card, may be limited to certain types of gamingapparatuses and/or certain STM cards. Thus, operation 712 may involvedetermining whether the STM that transmitted the request to update oneor more parameter values has permission to update those values. In oneor more embodiments, permission to transfer credit to or from a smartcard may be limited to a gaming machines and cashier's terminals.However, in different implementations, different security permissionsand/or rules may be used.

The determination made at operation 712 may be made at least in partbased on whether the request complies with one or more authenticationparameters specific to transferring credit. In one or more embodiments,transferring credit between a gaming apparatus and the smart card mayrequire that the user verify knowledge of a PIN that stored on the smartcard. In this case, a PIN may be collected from the user of the gamingapparatus and transmitted along with the request to transfer credit atoperation 708. Then, the PIN received with the request may be checkedagainst a PIN stored on the smart card, such as a PIN stored in thesecurity module 208 illustrated in FIG. 2. If the PINs do not match, therequest to transfer credit may be denied.

At 716, when it is determined that the request to transfer creditsatisfies one or more permissions and/or rules, the credit value storedon the smart card is updated according to the received transfer request.For example, if the received request represented a request to transfercredit from the smart card to the gaming apparatus, the credit valuestored on the smart card may be decreased by the amount of creditincluded in the request. As another example, if the received requestrepresented a request to transfer credit from the gaming apparatus tothe smart card, the credit value at the smart card may be increasedaccording to the value included with the received transfer request.

At 720, the credit value at the gaming apparatus is updated according tothe received request. For example, if the request represented a requestto transfer credit from the smart card to the gaming apparatus, thecredit value stored on the gaming apparatus may be increased accordingto the value included in the received request. As a different example,if the request represented a request to moved credit from the gamingapparatus to the smart card the credit value stored on the gamingapparatus may be decreased according to the amount included in thereceived request.

In one or more embodiments, the credit balance on the gaming apparatusmay be stored and updated in non-volatile memory associated with makingsecure transactions with smart cards. For example, the credit balancemay be stored in memory 144 associated with the SMIB 108 shown inFIG. 1. In this way, a credit balance may be safely maintained during asecure transaction with a smart card, even in the event of a systemfailure or power outage.

FIG. 8 shows a method 800 for automatically transferring credit to orfrom a smart card, performed in accordance with one embodiment of thepresent invention. In one or more embodiments, one or more operationsassociated with the Smart Card Credit Auto Transfer Procedure 800 may beperformed using one or more devices in a cashless gaming system. Forexample, the Smart Card Credit Auto Transfer Procedure 800 may beperformed at a gaming machine (e.g., gaming apparatus 104) incommunication with a smart card (e.g., via smart card slot 132).

In one or more embodiments, The Smart Card Credit Auto TransferProcedure 800 may be used to automatically transfer credit from a smartcard to a gaming machine. For example, when the credit balance on agaming machine drops below a predetermined threshold value, the SmartCard Credit Auto Transfer Procedure 800 may operate to automaticallytransfer credit from the smart card to the gaming machine. In this way,the user of a gaming machine may continue to play a gaming machine withadditional credit transferred as needed from the smart card withouthaving to specifically request that funds be transferred from the smartcard. In addition, the player need not transfer all of the credit storedon the smart card to the gaming machine at a given time, but rather canmaintain a credit balance on the gaming machine appropriate to theplayer's wishes.

At 804, a credit balance and one or more auto-transfer parameter valuesare retrieved from the smart card. In one or more embodiments, one ormore of these values may be stored in a module on the smart card, suchas wallet module 212. A procedure for retrieving one or more such valuesis described, for example, in relation to the Retrieve Smart CardParameter Value Procedure 500 illustrated in FIG. 5.

In one or more embodiments, the credit balance retrieved may be measuredin U.S. currency. However, in some implementations, the credit balanceretrieved may be measured in a different unit, such as casino credits orgame credits. For example, the smart card may be designed or configuredto store game-specific credits limited to use with one or more specificgames.

The one or more auto-transfer parameter values may include, for example,one or more of an auto-transfer threshold value, an auto-transferamount, and any other parameter values related to an auto-transfer. Theauto-transfer threshold value may represent, for example, a thresholdvalue for triggering an auto-transfer of funds from the smart card tothe gaming machine. The auto-transfer amount value may represent anamount of credit to transfer to the gaming machine when an auto-transferof credit is triggered.

In one or more embodiments, one or more of the auto-transfer parametersvalues may be user-configurable. In this way, a user may configure asmart card to always transfer a certain credit amount to the gamingmachine. It is anticipated that such configuration options may bebeneficial in encouraging smart card adoption, since many players preferto add a specific “lucky” amount of credit or cash to a gaming machineeach time.

In one or more embodiments, one or more of the auto-transfer parametersvalues may be system-configurable. For example, different STMs mayimpose different limits on credit transfer. A low-denomination gamingmachine, for instance, may limit the auto-transfer amount to avoid anunreasonable credit transfer (e.g., transferring $1,000 to a penny slotmachine).

At 808, a determination is made as to whether the credit level on thegaming machine is below the auto transfer threshold value. According todifferent embodiments, the determination may be made at differentlocations and/or by different software programs. In one or moreembodiments, the determination may be made by a program running on theCPU 140 of the SMIB 108 illustrated in FIG. 1. In a differentembodiment, the determination may be made at a different component ofthe gaming apparatus (e.g., the master gaming controller). In anotherembodiment, the determination may be made at the smart card.

At 812, instructions are transmitted to call a function on the smartcard to transfer credit between the smart card and the gaming apparatus.In one or more embodiments, the instructions are transmitted to thesmart card from a component associated with the gaming apparatus, suchas the SMIB 104, via an STM card associated with the gaming apparatus(e.g., an STM card in communication with SIM card slot 136).

According to various embodiments, various techniques may be used todetermine the amount of credit to request for transfer. For example, theamount of credit requested for transfer may be determined based on oneor more of the auto-transfer amount value, the auto-transfer thresholdvalue, and the current credit balance on the gaming machine. In one ormore embodiments, the amount of credit requested for transfer may besufficient to bring the current credit balance available on the gamingmachine up to the sum of the auto-transfer threshold and auto-transferamount. In some embodiments, the amount of credit requested for transfermay be equivalent (or substantially equivalent) to the auto-transferamount.

In one or more embodiments, the amount of credit requested for transfermay be limited by the credit balance retrieved from the smart card. Forexample, the gaming apparatus may not request to transfer more creditthan is available on the smart card. Alternately, the gaming apparatusmay instead rely on the smart card to transfer the appropriate amount ofcredit if the amount of credit requested exceeds the credit balancestored on the smart card.

At 816, a determination is made at an application running on the smartcard as to whether the request to transfer credit satisfies one or morepermissions and/or rules. In one or more embodiments, the determinationmade at 816 may be substantially similar to the determination made atoperation 712 illustrated in FIG. 7.

At 820, when it is determined that the request to transfer creditsatisfies one or more permissions and/or rules, the credit value storedon the smart card is updated according to the received transfer request.In one or more embodiments, updating the credit value at the smart cardas performed at operation 820 may be substantially similar to operation716 illustrated in FIG. 7.

At 824, the credit value at the gaming apparatus is updated according tothe received request. In one or more embodiments, updating the creditvalue at the gaming apparatus as performed at operation 824 may besubstantially similar to operation 720 illustrated in FIG. 7.

FIG. 9 shows a method 900 for cashing out a smart card, performed inaccordance with one embodiment of the present invention. The Smart CardCash Out Procedure 900 may be used to move credit stored on a gamingapparatus (e.g., a gaming machine) to a smart card.

Traditionally, a gaming machine may have responded to a request to cashout by providing cash or a ticket directly to a player. However,providing an item of value to the player without supervision from casinopersonnel may lead to concerns regarding security and/or fraudulenttransactions. As discussed herein, providing credit to a player via asmart card may, for example, ensure that one or more gaming transactionsare reviewed and/or verified before the player is provided with cash. Inaddition, using a smart card for cashing out the gaming machine mayallow a casino to limit the issuance of physical cash to certain securelocations within a casino (e.g., cashier's terminals). Finally, using asmart card for cashing out the gaming machine may allow paying a playerwithout any use of physical cash. For example, when the player takes thesmart card to a cashier, the player could be given a check instead ofcash.

However, it is anticipated that some players may initiate play at agaming machine without having a smart card. In order to permit such playwhile retaining one or more benefits associated with use of a smart cardfor cashing out a gaming machine, techniques are described forfacilitating cashing out a gaming machine by using a smart card evenwhen the gaming machine is not initially in communication with a smartcard.

At 904, a request is received to cash out the gaming machine. Accordingto various embodiments, the request may be received from a gamingmachine user, a casino employee, or software and/or hardware associatedwith the gaming machine. In some instances, the request to cash outreceived at 904 may represent a request to remove all the cash stored onthe smart card. However, in other instances, the request received tocash out at 904 may represent a request to transfer only some of thecash stored on the smart card.

In one or more embodiments, the request to cash out the smart card maybe received via user input device 116 illustrated in FIG. 1. Forexample, the amount of credit stored on the smart card may be displayedvia display 120 illustrated in FIG. 1. Then, a user may use the device116 to request that some or all of the credit stored on the smart cardbe transferred to the gaming apparatus for purposes of cashing out thesmart card.

At 908, a determination is made as to whether the gaming apparatus is incommunication with the smart card. For example, one or more componentsassociated with the cashless gaming system 100 illustrated in FIG. 1 maydetermine whether the gaming apparatus 104 is in communication with asmart card via smart card slot 132.

At 912, when it is determined that the gaming apparatus is incommunication with the smart card, credit may be transferred from thegaming machine to the smart card. As discussed herein, varioustechniques may be used to transfer credits between a gaming machine anda smart card. For example, credit may be transferred from the gamingmachine to the smart card using one or more operations described withrespect to Smart Card Credit Manual Transfer Procedure 700 illustratedin FIG. 7.

At 916, credit is transferred from the gaming machine to memoryassociated with smart card transactions. For example, credit may betransferred from the gaming machine to the memory 144 associated withthe SMIB 108 illustrated in FIG. 1. In one or more embodiments, thememory associated with smart card transactions may be nonvolatile memoryso that if the procedure for cashing out the gaming machine isinterrupted (e.g., by a power outage or gaming machine reset), thecredit will not be lost.

At 920, the gaming machine is removed from service. Removing the gamingmachine from service may involve, for example, placing the gamingmachine in a state in which no further wagering or game play may beconducted until the gaming machine is returned to service. In one ormore embodiments, certain functionality associated with the gamingmachine may remain in operation when the gaming machine is removed fromservice. For example, the gaming machine may permit continued operationof features related to ordering food and beverages, changing gameoptions, and/or other features that do not directly involve further gameplay.

At 924, a notification of a no-card cash out is sent to the gamingsystem. In one or more embodiments, the notification of a no-card cashout may be sent over the gaming network (e.g., via communication link124 illustrated in FIG. 1). In addition, or alternately, thenotification of a no-card cash out may be provided at the gamingmachine. For example, one or more audible and/or visible alarms may beactivated (e.g., a gaming machine candle may be lit). In someimplementations, the notification of a no-card cash out may be used toattract the attention of casino personnel. For example, casino personnelmay see that a player without a smart card would like to cash out agaming machine and respond by bringing a new smart card to the player.

At 928, a smart card is received at the smart card reader. For example,the smart card may be received at smart card reader 132 illustrated inFIG. 1. In one or more embodiments, the smart card may be brought by acasino employee to the gaming machine. In some embodiments, the smartcard may be supplied automatically by a device associated with thecashless gaming network. For example, the gaming machine may be coupledwith a device configured to supply a new smart card to a player if theplayer does not already possess a smart card. Either the player or thecasino employee may insert the smart card into the smart card reader.

In one or more embodiments, the smart card may be an unregistered or“day use” smart card (e.g., Unregistered Smart Card 200 illustrated inFIG. 2). However, in some embodiments the smart card may be registeredto the player (e.g., Registered Smart Card 300 illustrated in FIG. 3).For example, a casino employee who provides a smart card to the playermay use a portable handheld device to register the smart card for theplayer. As another example, a device at the gaming machine capable ofproviding a new smart card to the user may also be capable of performingone or more smart card registration operations (e.g., with supervisionby a casino employee, by providing a source of identificationinformation such as a credit card, etc.).

At 932, security is checked and the smart card is validated. In one ormore embodiments, the operations performed for checking security andvalidating the smart card may be substantially similar to authenticationoperations performed whenever a smart card is inserted into the smartcard reader. For example, one or more operations may be performed thatare related to establishing a secure communication session,authenticating the smart card with one or more remote servers,determining whether to permit offline use of the smart card, etc.

At 936, credit is transferred from the memory associated with smart cardtransactions to the smart card. For example, the credit may betransferred from memory 144 to a smart card in communication with smartcard slot 132. In one or more embodiments, one or more operationsperformed in conjunction with transferring credit to the smart card maybe substantially similar to operations discussed in relation to SmartCard Credit Manual Transfer Procedure 700 illustrated in FIG. 7.

At 940, the gaming machine is returned to service. In one or moreembodiments, the gaming machine may be returned to service automaticallyonce one or more operations associated with cashing out the gamingmachine are completed. However, in some embodiments, the gaming machinemay remain out of service until a casino employee (e.g., an employee whoprovided the smart card) provides input to the gaming machine. Forexample, the casino employee may supply a digital and/or physical key toreturn the gaming machine to service.

In one or more embodiments, one or more of the operations illustrated inFIG. 9 may be omitted. For example, credit may be moved directly fromthe gaming machine to the smart card without separately transferringcredit to memory specifically associated with smart card transactions.As another example, separate operations for checking security andvalidating the smart card may be unnecessary if the new smart card isprovided by the gaming machine.

In one or more embodiments, one or more operations illustrated in FIG. 9may be performed in a different order and/or concurrently. For example,the gaming machine may be removed from service before transferringcredit from the gaming machine to memory associated with smart cardtransactions. As another example, a notification of a no-card cash outmay be transmitted immediately upon making a determination at 908 thatthe gaming machine is not in communication with the smart card.

FIG. 10 shows a method 1000 for protecting smart card access, performedin accordance with one embodiment of the present invention. The SmartCard Access Protection Procedure 1000 may be performed at via one ormore devices in a cashless gaming system in communication with a smartcard. For example, the Smart Card Access Protection Procedure 1000 maybe performed at gaming apparatus 104 in communication with a smart cardvia smart card slot 132.

The Smart Card Access Protection procedure 1000 may be used to renderthe smart card at least partially inoperable in response to repeatedfailed access attempts. For example, if retrieving and/or updating oneor more values stored on the smart card requires that the user supplythe correct PIN, and the user repeatedly supplies incorrect PINs, thenthe smart card may be rendered at least partially inoperable. As anotherexample, if one or more values stored on the smart card may only beretrieved and/or updated from one or more specific types of gamingapparatuses, and repeated access attempts are made from one or moregaming apparatuses that do not have permission to retrieve and/or updatethe one or more values, the smart card may be rendered at leastpartially inoperable.

By rendering the smart card at least partially inoperable, an attackermay be prevented from altering one or more parameter values on the smartcard in order to compromise the security of the smart card. In addition,an attacker may be prevented from moving funds off of the smart card.

In one or more embodiments, one or more parameter values stored on thesmart card may be read, but not updated, after the smart card isrendered inoperable. This may allow a user to take the smart card to aterminal and/or casino employee for further assistance. For example, theuser may provide identification information to casino personnel and/or acashless gaming apparatus to verify the user's identity if the user haslost or forgotten the PIN or other security information stored on thesmart card. Then, one or more cash out procedures may be performed.Alternately, or additionally, the user may be issued a new smart card toreplace the inoperable smart card.

At 1004, instructions are transmitted from the cashless gaming apparatusto the smart card to call a function on the smart card to retrieveand/or update one or more parameter values. At 1008, a determination ismade as to whether the request to retrieve and/or update one or moreparameter values satisfies one or more permissions and/or rules. At1012, when it is determined that the request to retrieve and/or updateone or more parameter values satisfies the permissions and/or rules, theone or more parameter values are transmitted from the smart card to thegaming machine and/or updated on the smart card. In one or moreembodiments, operations 1004, 1008, and/or 1012 may be substantiallysimilar to operations 504, 508, and/or 512 illustrated in FIG. 5 and/oroperations 604, 608, and/or 612 illustrated in FIG. 6.

At 1020, when it is determined that the request to retrieve and/orupdate one or more parameter values does not satisfy the permissionsand/or rules, the number of failed access attempts is updated. In one ormore embodiments, the number of failed access attempts may be stored onthe smart card. For example, the number of failed access attempts may bea parameter value stored in the security module 208 illustrated in FIG.2 on the smart card.

Additionally, or alternately, the number of failed access attempts maybe stored at one or more remote servers, such as host systems 124illustrated in FIG. 1. For example, the smart card may transmitinformation associated with failed access attempts to host systems 124when the smart card authenticates with the host systems.

Additionally, or alternately, the number of failed access attempts maybe transmitted from the smart card to the gaming apparatus. Transmittingthe number of failed access attempts to the gaming apparatus may allow,for example, a user to be informed of the risk that the smart card willbe rendered inoperable. This may allow the user to request assistancefrom casino personnel (e.g., at a patron management terminal and/orcashier's terminal) instead of taking further action that may riskinvalidating the smart card. For example, a user may have forgotten thePIN stored on the card and may be attempting to guess the PIN value.

In one or more embodiments, updating the number of failed accessattempts may include updating information based on a time period or timestamp associated with previous failed access attempts. For example, eachfailed access attempt may be associated with a time stamp. In someinstances, failed access attempts that occurred in the past (e.g., morethan 2 hours ago), may be removed.

In one or more embodiments, the smart card, remote servers, and/orgaming apparatus may maintain more than one parameter values associatedwith the number of failed access attempts. For example, one parametervalue may be associated with failed access attempts to high securityfeatures, such as removing funds from the smart card, while anotherparameter value may be associated with failed access attempts to lowsecurity features, such as changing a preferred language. Thus, in someimplementations it may be possible to track failed access attemptswithout unnecessarily rendering the smart card inoperable.

At 1024, a determination is made as to whether the number of failedaccess attempts exceeds a threshold value. In one or more embodiments,the determination is made on the smart card. For example, the securitymodule 108 illustrated in FIG. 1 may make the determination.

The threshold value may represent a maximum number of failed accessattempts before the smart card is rendered inoperable. In one or moreembodiments, the threshold value may be stored on the smart card, forexample in the security module 108. Alternately, or additionally, athreshold value may be stored on the STM.

According to various embodiments, different threshold values may beused. In one or more embodiments, the threshold value is five failedaccess attempts since the most recent successful smart card use.However, in different embodiments, the threshold value may be anywherebetween 1 and 100.

In one or more embodiments, the threshold value may be updated uponrequest by one or more devices in the cashless gaming. For example, thethreshold value may be updated upon authentication of the smart cardwith host systems 124 illustrated in FIG. 1. This may allow a casino totailor the security provided by the smart card to the specific needs ofthe casino and/or particular users or groups of users. For example, asmart card that holds a relatively high credit balance may be assigned arelatively low failed access attempt threshold value, while a smart cardthat holds a relatively low credit balance may be assigned a relativelyhigh failed access attempt threshold value. As another example, a usermay request to raise or lower the failed access attempt threshold value.

In one or more embodiments, the smart card may store different thresholdvalues for different types of failed access attempts. For example, thesmart card may store a first failed access attempt threshold value forhigh security access attempts, such as attempts to remove credits fromthe smart card, and a second failed access attempt threshold value forlow security access attempts, such as attempts to change a preferredlanguage.

In one or more embodiments, one or more failed access attempt thresholdvalues may include information related to a time period or timeout. Forexample, a smart card may be rendered inoperable only when the number offailed access attempts exceeds a certain threshold value (e.g., threeattempts) in a certain period of time (e.g., 2 hours). In this way, asmart card will not be rendered inoperable based on failed accessattempts spaced far apart in time.

At 1028, when it is determined that the number of failed access attemptsexceeds a threshold value, the smart card is rendered at least partiallyinoperable. In one or more embodiments, rendering the smart cardinoperable may include performing at least one operation to physicallyprevent further updating of all or some parameter values stored on thecard. For example, one or more circuits and/or communication interfacesmay be fused or broken. As another example, a card may be broken,punched, bent, melted, or otherwise damaged or destroyed to render itinoperable.

In one or more embodiments, rendering the smart card inoperable mayinclude performing at least one software operation to prevent furtherupdating of the smart card. For example, one or more modules or appletsrunning on the smart card may store a value in memory that indicatesthat no further updating of parameter values may be performed.

In one or more embodiments, information may be retrievable from thesmart card by casino employees or systems once the smart card isrendered inoperable. For example, the player may be able to take thesmart card to a service desk and provide confirmation of identity. Thecredit balance then may be retrieved and compared against a verifiedcredit balance stored in the casino systems.

If the two values match, the player may be permitted to cash out thebalance or transfer the balance to a new smart card. Acquiring a newsmart card may require paying a fee (e.g., $5 or $10) and interactingwith casino employees or systems. Thus, if a player repeatedly requiresa new smart card, the player may incur costs and/or come to theattention of casino employees or systems. In this way, casinos maymonitor and prevent attempts to tamper with or gain unauthorized accessto smart cards in the cashless gaming system.

If instead the credit value stored on the smart card does not match thevalue stored in the casino systems, then the casino may investigate thecause of the discrepancy (e.g., systems failures, unauthorized smartcard access, etc.). The casino can then make an operational decisionabout whether to allow the player to cash out the smart card and whatthe value of the cash out should be. In this way, the casino may be ableto access at least some credit balance information even in the event oftotal system failure.

FIG. 11 shows a method 1100 for facilitating offline use of a smartcard, performed in accordance with one embodiment of the presentinvention.

It is anticipated that in some instances, a player may attempt to use asmart card at a gaming apparatus (e.g., a gaming machine) that is not incommunication with a cashless gaming server. For example, communicationsbetween the gaming machine and one or more cashless gaming servers maybe temporarily disrupted. In some instances, communications may betemporarily disrupted due to network failure, network congestion,routine maintenance, etc. As another example, it may be desirable topermit use of the smart card without requiring communication between thegaming machine and one or more cashless gaming servers. In someinstances, permitting use of the smart card without requiringauthentication with one or more cashless gaming servers may help avoidnetwork congestion, reduce usage of server resources, etc.

In one or more embodiments, offline smart card use may be facilitated bymaintaining a record of when a smart card was last authenticated. Then,the cashless gaming system can ensure that a smart card that has notbeen recently authenticated is authenticated before further use of thesmart card is permitted. Thus, the cashless gaming system may permitoffline use of the smart card while ensuring that the smart card is atleast occasionally authenticated with one or more cashless gamingservers. The Smart Card Offline Use Validation Procedure 1100illustrated in FIG. 11 is one example of how offline use of the smartcard may be facilitated.

At 1104, the offline window for smart card use is determined. Asdiscussed herein, the offline window may represent, for example, alength of time between the last authenticated use of a specific smartcard and the time in which it must be authenticated again before it canbe used further. In one or more embodiments, the offline window is 24hours, which means that if a given smart card has been authenticatedwith a remote cashless gaming server at a particular time (e.g., duringuse for a cashless gaming session), that smart card may be used for 24hours without requiring that the smart card be authenticated again witha remote cashless gaming server. In this way, a player may continue touse a smart card even if remote authentication of the card is notperformed.

Configuring the offline window may provide a casino with additionalcontrol over security in the cashless gaming system. Thus, according tovarious embodiments, the offline window may be determined in variousways. In one or more embodiments, the offline window may be a valuestored on an STM card in communication with the gaming apparatus. Forexample, the offline window may be stored on an STM card incommunication with SIM card slot 136 illustrated in FIG. 1. In someembodiments, the offline window may be a value stored on the smart card.For example, the offline window may be stored in wallet module 312illustrated in FIG. 3. In some embodiments, the offline window may bedetermined dynamically, and/or various offline windows may be used. Forexample, the gaming machine may read a credit balance stored on thesmart card and provide a shortened offline window for a card carrying arelatively high balance than for a card storing a relatively low creditbalance.

At 1108, the time of the most recent online use of the smart card may bedetermined. In some embodiments, the most recent online use of the smartcard may be the most recent time in which the smart card has beenauthenticated with one or more remote servers associated with thecashless gaming system (e.g., host systems 124 illustrated in FIG. 1).Authentication of the smart card with the one or more remote servers mayinvolve, for example, communication between the smart card and theremote servers to verify that the smart card is intact and has not beentampered with. In addition, or alternately, information related to oneor more offline cashless gaming transactions performed using the smartcard may be transmitted to the one or more remote servers forverification. For example, information stored on the smart card relatedto cashless transactions may be transmitted to the one or more remoteservers and compared with transaction information received from otherdevices in the cashless gaming system (e.g., one or more gamingapparatuses associated with the cashless transactions). In this way,cashless transactions performed during offline use of the smart card maybe at least periodically verified.

In one or more embodiments, determination of the time of the most recentonline use of the smart card may include reading one or more valuesstored on the smart card. For example, when a smart card isauthenticated with one or more remote servers, the one or more remoteservers may provide an encrypted token to the smart card (e.g.,encrypted with a private key) verifying that the smart card has beenauthenticated. Then, the smart card may provide this token to the gamingapparatus, which can verify that the token was provided by the one ormore remote servers (e.g., by decrypting with the corresponding publickey).

At 1112, a determination is made as to whether the most recent onlineuse of the smart card is outside the offline window. The determinationmay be made by comparing the offline window identified in operation 1104to the most recent online use of the smart card identified in operation1108.

At 1116, when it is determined that the last online use of the smartcard is outside the offline window, one or more operations related tooffline use of the smart card is not permitted. For example, if thesmart card has not been validated with the remote server for a period of3 days, and the window for offline use is 24 hours, offline use of thesmart card may not be permitted. In one or more embodiments, no furtheruse of the smart card will be permitted until the smart card isauthenticated. However, in some embodiments, certain limited uses of thesmart card may be permitted. For example, low security operations suchas changing the preferred language stored on the smart card may bepermitted. As another example, the player may be permitted to finish apartially completed transaction, such as moving credit from a gamingmachine to a smart card.

If the gaming apparatus is in communication with one or more cashlessgaming servers, the gaming apparatus may automatically initiatecommunications with the one or more cashless gaming servers forauthenticating the smart card. Alternately, or additionally, the gamingapparatus may inform the player that the smart card must beauthenticated before further use and/or request that the card beauthenticated.

At 1120, when it is determined that the most recent online use of thesmart card is inside the offline window, one or more operations relatedto offline use of the smart card may be permitted. For example, if theoffline window is 24 hours, but the smart card was last authenticated 5hours ago, offline use of the smart card may be permitted.

In some implementations, when the smart card is used in an offlinecashless gaming transaction, information related to the cashless gamingtransaction may be stored both on the smart card and on the gamingapparatus for later verification (e.g., before cashing out the smartcard). In this way, a casino may permit offline use of the smart cardwhile ensuring that the offline transactions are legitimate beforeproviding actual money based on the offline trans actions.

FIG. 12 shows a method 1200 for transmitting a notification regarding ablocked smart card, performed in accordance with one embodiment of thepresent invention.

In one or more embodiments, the Blocked Smart Card NotificationProcedure 1200 may be performed at various devices (e.g., gamingapparatus 104 illustrated in FIG. 1) in communication with a smart cardin a cashless gaming system. For example, the Blocked Smart CardNotification Procedure 1200 may be performed at a gaming machine.

The Blocked Smart Card Notification Procedure 1200 may be performed inconjunction with one or more additional procedures associated with useof the smart card. For example, the Blocked Smart Card NotificationProcedure 1200 may be performed before one or more of the proceduresillustrated in FIGS. 5-11 and 13.

In one or more embodiments, the blocked smart card notificationprocedure may be used to protect against unauthorized use of a smartcard (e.g., a smart card that has been lost or stolen). As anotherexample, the blocked smart card notification procedure 1200 may be usedto protect against errors in the case of mismatched smart cards and/ortransfer errors.

At 1204, identification information associated with the smart card isdetermined. According to various embodiments, the identificationinformation may include any information that may be used to identify thesmart card and/or the user associated with the smart card. For example,the identification may include one or more serial numbers, PINs, playeridentification numbers, cryptographic keys, etc.

In one or more embodiments, the identification information associatedwith the smart card may be determined by retrieving one or more valuesstored on the smart card. For example, one or more values may beretrieved using the Retrieve Smart Card Parameter Value Procedure 500illustrated in FIG. 5. As a different example, known informationregarding the smart card, such as the smart card serial number, may betransmitted to one or more remote servers (e.g., host systems 124illustrated in FIG. 1) to retrieve additional identificationinformation.

At 1208, a determination is made as to whether the smart card has beenblocked. In one or more embodiments, the determination as to whether thesmart card has been blocked may be made at the gaming apparatus (e.g.,at SMIB 108 illustrated in FIG. 1). In some instances, a gamingapparatus may store information used to identify blocked smart cards.For example, a gaming apparatus may periodically receive a list ofblocked smart cards from one or more remote servers. In this way, it maybe possible to prevent even certain offline uses of blocked smart cards.Additionally, and/or alternately, a gaming apparatus may directly queryone or more remote servers to determine whether a particular smart cardhas been blocked. In this case, the determination made at 1208 may bemade at either the server or at the gaming apparatus.

At 1212, when it is determined that the smart card has not been blocked,continued the use of the smart card for cashless gaming may bepermitted. For example, funds may be transmitted between the smart cardand the gaming apparatus, one or more parameter values stored on thesmart card may be retrieved and/or updated, and/or other operationsassociated with the smart card use may be performed.

At 1216, if instead it is determined that use of the smart card has beenblocked, credit is transferred from the gaming apparatus to the smartcard. In one or more embodiments, credits may transferred from thegaming apparatus to the smart card using, for example, one or moreoperations associated with Smart Card Credit Manual Transfer Procedure700 illustrated in FIG. 7. In a different embodiment, one or moredifferent techniques may be used for transferring funds to a blockedsmart card.

At 1220, a notification indicating that the smart card has been blockedis output. According to various embodiments, the notification may beoutput via one or more audible and/or visible indicators at the gamingapparatus. For example, the user may be presented with a message on adisplay (e.g., display 120 illustrated in FIG. 1) indicating that thesmart card has been blocked. As another example, a flash light and/oraudible alarm may be activated.

In one or more embodiments, the notification may include one or moreinstructions. For example, the notification may instruct the user totake the smart card to a different location in the gaming environment,such as a cashier's terminal. In this way, the condition that gave riseto the blocking of the smart card may be resolved. For example, a casinoemployee may examine one or more transaction records to reconcile orcorrect a credit transfer error.

In one or more embodiments, notification may be transmitted to one ormore casino systems and/or casino employees. For example, notificationmay be transmitted by an audible and/or visible alarm at the gamingmachine. In this way, casino personnel may be notified of a blockedsmart card and come to the assistance of the player. As another example,notification may be transmitted over a network. If the smart card wasblocked because it reported was lost or stolen, one or more casinoemployees and/or systems may be notified so that the actual status ofthe smart card maybe verified. In such instances, a notificationindicating that the smart card has been blocked may not be outputdirectly to the user. This may allow casino security to receive thenotification and/or direct personnel to identify the user of the blockedsmart card.

FIG. 13 shows a method 1300 for cashing out a missing smart card,performed in accordance with one embodiment of the present invention. Inone or more embodiments, missing smart card cash out procedure 1300 maybe used to retrieve stored on a smart card that is lost, stolen, orotherwise missing. For example, a user who notices that their smart cardis missing may report the loss to one or more casino employees and/orsystems (e.g., at a patron management and/or cashier's terminal). Then,the Missing Smart Card Cash Out Procedure 1300 may be used to insurethat all transactions completed using the missing smart card have beenrecorded and/or verified before transferring credit stored on the smartcard.

At 1304, a request is received to remove cash from the missing smartcard. For example, the request may be received by one or more of theuser, the cashier, and/or a program associated with cashless gaming. Inone or more embodiments, a request was received at a cashier's terminal.

At 1308, a determination is made as to whether the use of the smart cardhas been blocked. In one or more embodiments, the determination made at1308 may be substantially similar to the operations described withrespect to reference number 1208 illustrated in FIG. 12.

At 1312, if it is determined that the smart card has not been blocked,use of the smart card may be blocked. In one or more embodiments, theuse of the smart card is blocked by transmitting instructions to one ormore remote servers associated with cashless gaming. In this way,further use of the smart card for cashless gaming may be prevented untilthe status of the smart card may be determined.

In one or more embodiments, the instructions transmitted to the one ormore remote servers may include identification information associatedwith the player making the request to remove cash from the missing smartcard. The information may include personal identification information,such as name, date of birth, address, or any other type of information.Collecting and transmitting such information may assist in preventingplayers from making fraudulent requests to remove cash from smart cards(e.g., smart cards that are not their own).

At 1316, when it is determined that use of the smart card has beenblocked, the offline window for smart card is determined. In at leastone embodiments, determining the offline window for smart card use asillustrated at 1316 may be substantially similar to operation 1104illustrated in FIG. 11.

At 1320, a determination is made as to when the smart card was blocked.In one or more embodiments, the determination as to whether the smartcard was blocked may be made by transmitting a request to one or moreremote systems, such as host systems 124 illustrated in FIG. 1.Additionally, and/or alternately, the gaming apparatus may maintain alist of blocked smart cards transmitted periodically from one or moreremote servers, along with time stamps indicating when each card wasblocked.

At 1324, a determination is made as to whether the time when the smartcard was blocked falls outside the offline window associated with thesmart card. The determination may be made by comparing the offlinewindow identified in operation 1316 to the time at which use of thesmart card was blocked as determined at operation 1320.

At 1328, when it is determined that the time in which the smart card wasblocked falls outside the offline window for smart card use, one or moreoperations may be performed for cashing out and invalidating the smartcard. For example, the player may be provided with actual cashcorresponding to a verified balance stored on the smart card. As anotherexample, the player may be provided with a new smart card storing acredit balance. In addition, or alternately, further use of the blockedsmart card may be permanently prevented.

In some instances, a smart card may become blocked by the cashlessgaming system due to a mismatch between one or more balances ortransaction records stored on the smart card and one or more balances ortransactions records stored at a cashless gaming server. Such a mismatchmay occur, for instance, if gaming machine electronics becamepermanently disabled before a transaction could be transmitted to theserver. Accordingly, a cashless gaming system may enforce securitypolicies to handle mismatches.

For example, one security policy may be that a user (e.g., a casinoemployee) cannot permanently clear a system block (e.g., due to amismatch in the transaction records). Thus, a casino employee withappropriate security clearances may be able to access information storedon a block smart card. However, the smart card may remain blocked untilthe system block is cleared by the cashless gaming system itself, forexample by reconciling the mismatched transaction records.

As another example, one security policy may be that writing to a card tomodify the transaction record is prohibited by the system and/orphysically impossible. If there is a transaction recorded in thedatabase but not on a smart card, for instance, then it is likely thatthe smart card either is malfunctioning or has been tampered with. Insuch a scenario, a casino may choose to issue a new card, but themismatched card may remain blocked and unaltered in order to retain aclear record of any transactions. Additionally, or alternately, a casinoemployee (e.g., a cashier) may read the last known balance from thedatabase and/or smart card and make an operational choice as to theamount of funds to provide the player upon cash-out.

As yet another example, one security policy may be that only certaincasino personnel (e.g., supervisors) have permission to modify atransaction database at a cashless gaming server. The casino may know,for instance, that a specific slot machine overloaded and becameinoperable. Therefore, the casino may choose to honor transactions thatwere stored on the smart card but not recorded on the cashless gamingserver. This may be accomplished by manually modifying the transactionsdatabase on the cashless gaming server to match the transaction recordon the smart card.

Gaming Machine

FIG. 14 shows a perspective view of a gaming machine 2, constructed inaccordance with one embodiment of the present invention. The gamingdevices and gaming functions described with respect to at least FIG. 14may be incorporated as components of the ECI's described above withrespect to at least FIGS. 1 thru 5B and 9A-9D. Further, the gamingdevices may be operated in accordance with instructions received from aremote host in communication with the gaming machine. In some instance,a host-controlled process executed on the gaming machine may share agaming device with a process controlled by the master gaming controller46 on the gaming machine.

As illustrated in the example of FIG. 14, machine 2 includes a maincabinet 4, which generally surrounds the machine interior and isviewable by users. The main cabinet includes a main door 8 on the frontof the machine, which opens to provide access to the interior of themachine.

In one embodiment, attached to the main door is at least one paymentacceptor 28 and a bill validator 30, and a coin tray 38. In oneembodiment, the payment acceptor may include a coin slot and a payment,note or bill acceptor, where the player inserts money, coins or tokens.The player can place coins in the coin slot or paper money, a ticket orvoucher into the payment, note or bill acceptor. In other embodiments,devices such as readers or validators for credit cards, debit cards orcredit slips may accept payment. In one embodiment, a player may insertan identification card into a card reader of the gaming machine. In oneembodiment, the identification card is a smart card having a programmedmicrochip or a magnetic strip coded with a player's identification,credit totals (or related data) and other relevant information. Inanother embodiment, a player may carry a portable device, such as a cellphone, a radio frequency identification tag or any other suitablewireless device, which communicates a player's identification, credittotals (or related data) and other relevant information to the gamingmachine. In one embodiment, money may be transferred to a gaming machinethrough electronic funds transfer. When a player funds the gamingmachine, the master gaming controller 46 or another logic device coupledto the gaming machine determines the amount of funds entered anddisplays the corresponding amount on the credit or other suitabledisplay as described above.

In one embodiment attached to the main door are a plurality ofplayer-input switches or buttons 32. The input switches can include anysuitable devices which enables the player to produce an input signalwhich is received by the processor. In one embodiment, after appropriatefunding of the gaming machine, the input switch is a game activationdevice, such as a pull arm or a play button which is used by the playerto start any primary game or sequence of events in the gaming machine.The play button can be any suitable play activator such as a bet onebutton, a max bet button or a repeat the bet button. In one embodiment,upon appropriate funding, the gaming machine may begin the game playautomatically. In another embodiment, upon the player engaging one ofthe play buttons, the gaming machine may automatically activate gameplay.

In one embodiment, one input switch is a bet one button. The playerplaces a bet by pushing the bet one button. The player can increase thebet by one credit each time the player pushes the bet one button. Whenthe player pushes the bet one button, the number of credits shown in thecredit display preferably decreases by one, and the number of creditsshown in the bet display preferably increases by one. In anotherembodiment, one input switch is a bet max button (not shown), whichenables the player to bet the maximum wager permitted for a game of thegaming machine.

In one embodiment, one input switch is a cash-out button. The player maypush the cash-out button and cash out to receive a cash payment or othersuitable form of payment corresponding to the number of remainingcredits. In one embodiment, when the player cashes out, the player mayreceive the coins or tokens in a coin payout tray. In one embodiment,when the player cashes out, the player may receive other payoutmechanisms such as tickets or credit slips redeemable by a cashier (orother suitable redemption system) or funding to the player'selectronically recordable identification card. Details of ticketing orvoucher system that may be utilized with the present invention aredescribed in co-pending U.S. patent application Ser. No. 10/406,911,filed Apr. 2, 2003, by Rowe, et al., and entitled, “Cashless TransactionClearinghouse,” which is incorporated herein by reference and for allpurposes.

In one embodiment, one input switch is a touch-screen coupled with atouch-screen controller, or some other touch-sensitive display overlayto enable for player interaction with the images on the display. Thetouch-screen and the touch-screen controller may be connected to a videocontroller. A player may make decisions and input signals into thegaming machine by touching the touch-screen at the appropriate places.One such input switch is a touch-screen button panel.

In one embodiment, the gaming machine may further include a plurality ofcommunication ports for enabling communication of the gaming machineprocessor with external peripherals, such as external video sources,expansion buses, game or other displays, an SCSI port or a key pad.

As seen in FIG. 14, viewable through the main door is a video displaymonitor 34 and an information panel 36. The display monitor 34 willtypically be a cathode ray tube, high resolution flat-panel LCD, SEDbased-display, plasma display, a television display, a display based onlight emitting diodes (LED), a display based on a plurality of organiclight-emitting diodes (OLEDs), a display based on polymer light-emittingdiodes (PLEDs), a display including a projected and/or reflected imageor any other suitable electronic device or display. The informationpanel 36 or belly-glass 40 may be a static back-lit, silk screened glasspanel with lettering to indicate general game information including, forexample, a game denomination (e.g. $0.25 or $1) or a dynamic display,such as an LCD, an OLED or E-INK display. In another embodiment, atleast one display device may be a mobile display device, such as a PDAor tablet PC, that enables play of at least a portion of the primary orsecondary game at a location remote from the gaming machine. The displaydevices may be of any suitable size and configuration, such as a square,a rectangle or an elongated rectangle.

The display devices of the gaming machine are configured to display atleast one and preferably a plurality of game or other suitable images,symbols and indicia such as any visual representation or exhibition ofthe movement of objects such as mechanical, virtual or video reels andwheels, dynamic lighting, video images, images of people, characters,places, things and faces of cards, and the like. In one alternativeembodiment, the symbols, images and indicia displayed on or of thedisplay device may be in mechanical form. That is, the display devicemay include any electromechanical device, such as one or more mechanicalobjects, such as one or more rotatable wheels, reels or dice, configuredto display at least one or a plurality of game or other suitable images,symbols or indicia. In another embodiment, the display device mayinclude an electromechanical device adjacent to a video display, such asa video display positioned in front of a mechanical reel. In anotherembodiment, the display device may include dual layered video displayswhich co-act to generate one or more images.

The bill validator 30, player-input switches 32, video display monitor34, and information panel are gaming devices that may be used to play agame on the game machine 2. According to a specific embodiment, thedevices may be controlled by code executed by a master gaming controller46 housed inside the main cabinet 4 of the machine 2. The master gamingcontroller may include one or more processors including general purposeand specialized processors, such as graphics cards, and one or morememory devices including volatile and non-volatile memory. The mastergaming controller 46 may periodically configure and/or authenticate thecode executed on the gaming machine.

In one embodiment, the gaming machine may include a sound generatingdevice coupled to one or more sounds cards. In one embodiment, the soundgenerating device includes at least one and preferably a plurality ofspeakers or other sound generating hardware and/or software forgenerating sounds, such as playing music for the primary and/orsecondary game or for other modes of the gaming machine, such as anattract mode. In one embodiment, the gaming machine provides dynamicsounds coupled with attractive multimedia images displayed on one ormore of the display devices to provide an audio-visual representation orto otherwise display full-motion video with sound to attract players tothe gaming machine. During idle periods, the gaming machine may displaya sequence of audio and/or visual attraction messages to attractpotential players to the gaming machine. The videos may also becustomized for or to provide any appropriate information.

In one embodiment, the gaming machine may include a sensor, such as acamera that is selectively positioned to acquire an image of a playeractively using the gaming machine and/or the surrounding area of thegaming machine. In one embodiment, the camera may be configured toselectively acquire still or moving (e.g., video) images and may beconfigured to acquire the images in either an analog, digital or othersuitable format. The display devices may be configured to display theimage acquired by the camera as well as display the visiblemanifestation of the game in split screen or picture-in-picture fashion.For example, the camera may acquire an image of the player and theprocessor may incorporate that image into the primary and/or secondarygame as a game image, symbol or indicia.

Games Played

Many different types of games, including mechanical slot games, videoslot games, video poker, video black jack, video pachinko and lottery,may be provided with gaming machines of this present invention. Inparticular, the gaming machine 2 may be operable to provide a play ofmany different games of chance. The games may be differentiatedaccording to themes, sounds, graphics, type of game (e.g., slot game vs.card game), denomination, number of paylines, maximum jackpot,progressive or non-progressive, bonus games, etc.

In one embodiment, the gaming machine 2 may be operable to enable aplayer to select a game of chance to play from a plurality of differentgames available on the gaming machine. For example, the gaming machinemay provide a menu with a list of the different games that are availablefor play on the gaming machine and a player may be able to select fromthe list a first game of chance that they wish to play. In one suchembodiment, a memory device of the remote host stores different gameprograms and instructions, executable by a gaming machine processor, tocontrol the gaming machine. Each executable game program represents adifferent game or type of game, which may be played on one or more ofthe gaming machines in the gaming system. Such different games mayinclude the same or substantially the same game play with different paytables. In different embodiments, the executable game program is for aprimary game, a secondary game or both. In another embodiment, the gameprogram may be executable as a secondary game to be played simultaneouswith the play of a primary game (which may be downloaded to or fixed onthe gaming machine) or vice versa.

In one such embodiment, each gaming machine includes at least one ormore display devices and/or one or more input switches for interactionwith a player. A local processor, such as the above-described gamingmachine processor or a processor of a local server, is operable with thedisplay device(s) and/or the input switch(s) of one or more of thegaming machines. In operation, the remote host is operable tocommunicate one or more of the stored game programs to at least onelocal gaming machine processor. In different embodiments, the storedgame programs are communicated or delivered by embedding thecommunicated game program in a device or a component (e.g., a microchipto be inserted in a gaming machine), writing the game program on a discor other media, downloading or streaming the game program over adedicated data network, internet or a telephone line. In differentembodiments, the stored game programs are downloaded in response to aplayer inserting a player tracking card, a player selecting a specificgame program, a player inserting a designated wager amount, the remotehost communicating data to the gaming device regarding an upcomingtournament or promotion or any other suitable trigger. After the storedgame programs are communicated from the remote host, the local gamingmachine processor executes the communicated program to facilitate playof the communicated program by a player through the display device(s)and/or input switch(s) of the gaming machine. That is, when a gameprogram is communicated to a local gaming machine processor, the localgaming machine processor changes the game or type of game played at thegaming machine.

In one embodiment, the various games available for play on the gamingmachine 2 may be stored as game software on a mass storage device in thegaming machine. In one such embodiment, the memory device of the gamingmachine stores program codes and instructions, executable by the gamingmachine processor, to control the games available for play on the gamingmachine. The memory device also stores other data such as image data,event data, player input data, random or pseudo-random numbergenerators, pay-table data or information and applicable game rules thatrelate to the play of the gaming machine. In another embodiment, thegames available for play on the gaming machine may be generated on aremote gaming device but then displayed on the gaming machine.

In one embodiment, the gaming machine 2 may execute game software, suchas but not limited to video streaming software that enables the game tobe displayed on the gaming machine. When a game is stored on the gamingmachine 2, it may be loaded from the mass storage device into a RAM forexecution. In some cases, after a selection of a game, the game softwarethat enables the selected game to be generated may be downloaded from aremote gaming device, such as another gaming machine.

As illustrated in the example of FIG. 14, the gaming machine 2 includesa top box 6, which sits on top of the main cabinet 4. The top box 6houses a number of devices, which may be used to add features to a gamebeing played on the gaming machine 2, including speakers 10, 12, 14, aticket printer 18 which prints bar-coded tickets 20, a key pad 22 forentering player tracking information, a display 16 (e.g., a video LCDdisplay) for displaying player tracking information, a card reader 24for entering a magnetic striped card containing player trackinginformation, and a video display screen 45. The ticket printer 18 may beused to print tickets for a cashless ticketing system. Further, the topbox 6 may house different or additional devices not illustrated in FIG.14. For example, the top box may include a bonus wheel or a back-litsilk screened panel which may be used to add bonus features to the gamebeing played on the gaming machine. As another example, the top box mayinclude a display for a progressive jackpot offered on the gamingmachine. During a game, these devices are controlled and powered, inpart, by circuitry (e.g. a master gaming controller 46) housed withinthe main cabinet 4 of the machine 2.

It will be appreciated that gaming machine 2 is but one example from awide range of gaming machine designs on which the present invention maybe implemented. For example, not all suitable gaming machines have topboxes or player tracking features. Further, some gaming machines haveonly a single game display—mechanical or video, while others may havemultiple displays.

Networks

In various embodiments, the remote gaming device may be connected to thehost computer via a network of some type such as a local area network, awide area network, an intranet or the Internet. In one such embodiment,a plurality of the gaming machines may be capable of being connectedtogether through a data network. In one embodiment, the data network isa local area network (LAN), in which one or more of the gaming machinesare substantially proximate to each other and an on-site remote host asin, for example, a gaming establishment or a portion of a gamingestablishment. In another embodiment, the data network is a wide areanetwork (WAN) in which one or more of the gaming machines are incommunication with at least one off-site remote host. In thisembodiment, the plurality of gaming machines may be located in adifferent part of the gaming establishment or within a different gamingestablishment than the off-site remote host. Thus, the WAN may includean off-site remote host and an off-site gaming machine located withingaming establishments in the same geographic area, such as a city orstate. The WAN gaming system may be substantially identical to the LANgaming system described above, although the number of gaming machines ineach system may vary relative to each other.

In another embodiment, the data network is an internet or intranet. Inthis embodiment, the operation of the gaming machine can be viewed atthe gaming machine with at least one internet browser. In thisembodiment, operation of the gaming machine and accumulation of creditsmay be accomplished with only a connection to the central server orcontroller (the internet/intranet server) through a conventional phoneor other data transmission line, digital subscriber line (DSL), T-1line, coaxial cable, fiber optic cable, or other suitable connection. Inthis embodiment, players may access an internet game page from anylocation where an internet connection and computer, or other internetfacilitator is available. The expansion in the number of computers andnumber and speed of internet connections in recent years increasesopportunities for players to play from an ever-increasing number ofremote sites. It should be appreciated that enhanced bandwidth ofdigital wireless communications may render such technology suitable forsome or all communications, particularly if such communications areencrypted. Higher data transmission speeds may be useful for enhancingthe sophistication and response of the display and interaction with theplayer.

In another embodiment, the remote gaming device may be a portable gamingdevice such as but not limited to a cell phone, a personal digitalassistant, and a wireless game player. Images rendered from 3-D gamingenvironments may be displayed on portable gaming devices that are usedto play a game of chance. Further a gaming machine or server may includegaming logic for commanding a remote gaming device to render an imagefrom a virtual camera in a 3-D gaming environments stored on the remotegaming device and to display the rendered image on a display located onthe remote gaming device. In addition, various combinations of gamingdevices are possible on the gaming machine. For example, some gamingmachine only accept cash, cashless vouchers or electronic fund transfersand do not include coin acceptors or coin hoppers. Thus, those of skillin the art will understand that the present invention, as describedbelow, can be deployed on most any gaming machine now available orhereafter developed.

In another embodiment, the gaming machine disclosed herein is operableover a wireless network, such as part of a wireless gaming system. Inthis embodiment, the gaming machine may be a hand held device, a mobiledevice or any other suitable wireless device that enables a player toplay any suitable game at a variety of different locations. It should beappreciated that a gaming machine as disclosed herein may be a devicethat has obtained approval from a regulatory gaming commission or adevice that has not obtained approval from a regulatory gamingcommission.

Gaming Machine Vs. General-Purpose Computer

Some preferred gaming machines of the present assignee are implementedwith special features and/or additional circuitry that differentiatesthem from general-purpose computers (e.g., desktop PC's and laptops).Gaming machines are highly regulated to ensure fairness and, in manycases, gaming machines are operable to dispense monetary awards ofmultiple millions of dollars. Therefore, to satisfy security andregulatory requirements in a gaming environment, hardware and softwarearchitectures may be implemented in gaming machines that differsignificantly from those of general-purpose computers. A description ofgaming machines relative to general-purpose computing machines and someexamples of the additional (or different) components and features foundin gaming machines are described below.

At first glance, one might think that adapting PC technologies to thegaming industry would be a simple proposition because both PCs andgaming machines employ microprocessors that control a variety ofdevices. However, because of such reasons as 1) the regulatoryrequirements that are placed upon gaming machines, 2) the harshenvironment in which gaming machines operate, 3) security requirementsand 4) fault tolerance requirements, adapting PC technologies to agaming machine can be quite difficult. Further, techniques and methodsfor solving a problem in the PC industry, such as device compatibilityand connectivity issues, might not be adequate in the gamingenvironment. For instance, a fault or a weakness tolerated in a PC, suchas security holes in software or frequent crashes, may not be toleratedin a gaming machine because in a gaming machine these faults can lead toa direct loss of funds from the gaming machine, such as stolen cash orloss of revenue when the gaming machine is not operating properly.

For the purposes of illustration, a few differences between PC systemsand gaming systems will be described. A first difference between gamingmachines and common PC based computers systems is that gaming machinesare designed to be state-based systems. In a state-based system, thesystem stores and maintains its current state in a non-volatile memory,such that, in the event of a power failure or other malfunction thegaming machine will return to its current state when the power isrestored. For instance, if a player was shown an award for a game ofchance and, before the award could be provided to the player the powerfailed, the gaming machine, upon the restoration of power, would returnto the state where the award is indicated. As anyone who has used a PC,knows, PCs are not state machines and a majority of data is usually lostwhen a malfunction occurs. This requirement affects the software andhardware design on a gaming machine.

A second important difference between gaming machines and common PCbased computer systems is that for regulation purposes, the software onthe gaming machine used to generate the game of chance and operate thegaming machine has been designed to be static and monolithic to preventcheating by the operator of gaming machine. For instance, one solutionthat has been employed in the gaming industry to prevent cheating andsatisfy regulatory requirements has been to manufacture a gaming machinethat can use a proprietary processor running instructions to generatethe game of chance from an EPROM or other form of non-volatile memory.The coding instructions on the EPROM are static (non-changeable) andmust be approved by a gaming regulators in a particular jurisdiction andinstalled in the presence of a person representing the gamingjurisdiction. Any changes to any part of the software required togenerate the game of chance, such as adding a new device driver used bythe master gaming controller to operate a device during generation ofthe game of chance can require a new EPROM to be burnt, approved by thegaming jurisdiction and reinstalled on the gaming machine in thepresence of a gaming regulator. Regardless of whether the EPROM solutionis used, to gain approval in most gaming jurisdictions, a gaming machinemust demonstrate sufficient safeguards that prevent an operator orplayer of a gaming machine from manipulating hardware and software in amanner that gives them an unfair and some cases an illegal advantage.The gaming machine should have a means to determine if the code it willexecute is valid. If the code is not valid, the gaming machine must havea means to prevent the code from being executed. The code validationrequirements in the gaming industry affect both hardware and softwaredesigns on gaming machines.

A third important difference between gaming machines and common PC basedcomputer systems is the number and kinds of peripheral devices used on agaming machine are not as great as on PC based computer systems.Traditionally, in the gaming industry, gaming machines have beenrelatively simple in the sense that the number of peripheral devices andthe number of functions the gaming machine has been limited. Further, inoperation, the functionality of gaming machines were relatively constantonce the gaming machine was deployed, i.e., new peripherals devices andnew gaming software were infrequently added to the gaming machine. Thisdiffers from a PC where users will go out and buy different combinationsof devices and software from different manufacturers and connect them toa PC to suit their needs depending on a desired application. Therefore,the types of devices connected to a PC may vary greatly from user touser depending in their individual requirements and may varysignificantly over time.

Although the variety of devices available for a PC may be greater thanon a gaming machine, gaming machines still have unique devicerequirements that differ from a PC, such as device security requirementsnot usually addressed by PCs. For instance, monetary devices, such ascoin dispensers, bill validators and ticket printers and computingdevices that are used to govern the input and output of cash to a gamingmachine have security requirements that are not typically addressed inPCs. Therefore, many PC techniques and methods developed to facilitatedevice connectivity and device compatibility do not address the emphasisplaced on security in the gaming industry.

To address some of the issues described above, a number ofhardware/software components and architectures are utilized in gamingmachines that are not typically found in general purpose computingdevices, such as PCs. These hardware/software components andarchitectures, as described below in more detail, include but are notlimited to watchdog timers, voltage monitoring systems, state-basedsoftware architecture and supporting hardware, specialized communicationinterfaces, security monitoring and trusted memory.

For example, a watchdog timer is normally used in International GameTechnology (IGT) gaming machines to provide a software failure detectionmechanism. In a normally operating system, the operating softwareperiodically accesses control registers in the watchdog timer subsystemto “re-trigger” the watchdog. Should the operating software fail toaccess the control registers within a preset timeframe, the watchdogtimer will timeout and generate a system reset. Typical watchdog timercircuits include a loadable timeout counter register to enable theoperating software to set the timeout interval within a certain range oftime. A differentiating feature of the some preferred circuits is thatthe operating software cannot completely disable the function of thewatchdog timer. In other words, the watchdog timer always functions fromthe time power is applied to the board.

IGT gaming computer platforms preferably use several power supplyvoltages to operate portions of the computer circuitry. These can begenerated in a central power supply or locally on the computer board. Ifany of these voltages falls out of the tolerance limits of the circuitrythey power, unpredictable operation of the computer may result. Thoughmost modern general-purpose computers include voltage monitoringcircuitry, these types of circuits only report voltage status to theoperating software. Out of tolerance voltages can cause softwaremalfunction, creating a potential uncontrolled condition in the gamingcomputer. Gaming machines of the present assignee typically have powersupplies with tighter voltage margins than that required by theoperating circuitry. In addition, the voltage monitoring circuitryimplemented in IGT gaming computers typically has two thresholds ofcontrol. The first threshold generates a software event that can bedetected by the operating software and an error condition generated.This threshold is triggered when a power supply voltage falls out of thetolerance range of the power supply, but is still within the operatingrange of the circuitry. The second threshold is set when a power supplyvoltage falls out of the operating tolerance of the circuitry. In thiscase, the circuitry generates a reset, halting operation of thecomputer.

The standard method of operation for IGT gaming machine game software isto use a state machine. Different functions of the game (bet, play,result, points in the graphical presentation, etc.) may be defined as astate. When a game moves from one state to another, critical dataregarding the game software is stored in a custom non-volatile memorysubsystem. This is critical to ensure the player's wager and credits arepreserved and to minimize potential disputes in the event of amalfunction on the gaming machine.

In general, the gaming machine does not advance from a first state to asecond state until critical information that enables the first state tobe reconstructed is stored. This feature enables the game to recoveroperation to the current state of play in the event of a malfunction,loss of power, etc that occurred just prior to the malfunction. Afterthe state of the gaming machine is restored during the play of a game ofchance, game play may resume and the game may be completed in a mannerthat is no different than if the malfunction had not occurred.Typically, battery backed RAM devices are used to preserve this criticaldata although other types of non-volatile memory devices may beemployed. These memory devices are not used in typical general-purposecomputers.

As described in the preceding paragraph, when a malfunction occursduring a game of chance, the gaming machine may be restored to a statein the game of chance just prior to when the malfunction occurred. Therestored state may include metering information and graphicalinformation that was displayed on the gaming machine in the state priorto the malfunction. For example, when the malfunction occurs during theplay of a card game after the cards have been dealt, the gaming machinemay be restored with the cards that were previously displayed as part ofthe card game. As another example, a bonus game may be triggered duringthe play of a game of chance where a player is required to make a numberof selections on a video display screen. When a malfunction has occurredafter the player has made one or more selections, the gaming machine maybe restored to a state that shows the graphical presentation at the justprior to the malfunction including an indication of selections that havealready been made by the player. In general, the gaming machine may berestored to any state in a plurality of states that occur in the game ofchance that occurs while the game of chance is played or to states thatoccur between the play of a game of chance.

Game history information regarding previous games played such as anamount wagered, the outcome of the game and so forth may also be storedin a non-volatile memory device. The information stored in thenon-volatile memory may be detailed enough to reconstruct a portion ofthe graphical presentation that was previously presented on the gamingmachine and the state of the gaming machine (e.g., credits) at the timethe game of chance was played. The game history information may beutilized in the event of a dispute. For example, a player may decidethat in a previous game of chance that they did not receive credit foran award that they believed they won. The game history information maybe used to reconstruct the state of the gaming machine prior, duringand/or after the disputed game to demonstrate whether the player wascorrect or not in their assertion. Further details of a state basedgaming system, recovery from malfunctions and game history are describedin U.S. Pat. No. 6,804,763, tided “High Performance Battery Backed RAMInterface”, U.S. Pat. No. 6,863,608, tided “Frame Capture of Actual GamePlay,” U.S. application Ser. No. 10/243,104, tided, “Dynamic NV-RAM,”and U.S. application Ser. No. 10/758,828, tided, “Frame Capture ofActual Game Play,” each of which is incorporated by reference and forall purposes.

In particular embodiments, a state of a gaming device may bereconstructed from game history information stored in multiplelocations. For instance, in one embodiment, a gaming device operable toprovide an ECI and a game interface simultaneously may not store stateinformation for the ECI but only for the game interface. Thus, toreconstruct the state of gaming device including the ECI in a dispute,after a malfunction or after a power-failure, game history informationmay have to be retrieved from a local memory source on the gaming deviceand a remote memory source located on a remote host that provides theECI. For example, the remote and gaming machine may store correlationinformation, such as timing information or referential information, thatallows events on the gaming machine to be correlated to events occurringon the remote host. The correlation information stored at the gamingmachine and/or remote host may be used to synchronize the reconstructionof a game state on the gaming machine. In a particular embodiment, aremote host that provides ECI services to a gaming device may provide anECI that allows archival information regarding ECIs displayed on agaming device to be retrieved.

Another feature of gaming machines, such as IGT gaming computers, isthat they often include unique interfaces, including serial interfaces,to connect to specific subsystems internal and external to the gamingmachine. The serial devices may have electrical interface requirementsthat differ from the “standard” EIA 232 serial interfaces provided bygeneral-purpose computers. These interfaces may include EIA 485, EIA422, Fiber Optic Serial, optically coupled serial interfaces, currentloop style serial interfaces, etc. In addition, to conserve serialinterfaces internally in the gaming machine, serial devices may beconnected in a shared, daisy-chain fashion where multiple peripheraldevices are connected to a single serial channel.

The serial interfaces may be used to transmit information usingcommunication protocols that are unique to the gaming industry. Forexample, IGT's Netplex is a proprietary communication protocol used forserial communication between gaming devices. As another example, SAS isa communication protocol used to transmit information, such as meteringinformation, from a gaming machine to a remote device. Often SAS is usedin conjunction with a player tracking system.

IGT gaming machines may alternatively be treated as peripheral devicesto a casino communication controller and connected in a shared daisychain fashion to a single serial interface. In both cases, theperipheral devices are preferably assigned device addresses. If so, theserial controller circuitry must implement a method to generate ordetect unique device addresses. General-purpose computer serial portsare not able to do this.

Security monitoring circuits detect intrusion into an IGT gaming machineby monitoring security switches attached to access doors in the gamingmachine cabinet. Preferably, access violations result in suspension ofgame play and can trigger additional security operations to preserve thecurrent state of game play. These circuits also function when power isoff by use of a battery backup. In power-off operation, these circuitscontinue to monitor the access doors of the gaming machine. When poweris restored, the gaming machine can determine whether any securityviolations occurred while power was off, e.g., via software for readingstatus registers. This can trigger event log entries and further dataauthentication operations by the gaming machine software.

Trusted memory devices and/or trusted memory sources are preferablyincluded in an IGT gaming machine computer to ensure the authenticity ofthe software that may be stored on less secure memory subsystems, suchas mass storage devices. Trusted memory devices and controllingcircuitry are typically designed to not enable modification of the codeand data stored in the memory device while the memory device isinstalled in the gaming machine. The code and data stored in thesedevices may include authentication algorithms, random number generators,authentication keys, operating system kernels, etc. The purpose of thesetrusted memory devices is to provide gaming regulatory authorities aroot trusted authority within the computing environment of the gamingmachine that can be tracked and verified as original. This may beaccomplished via removal of the trusted memory device from the gamingmachine computer and verification of the secure memory device contentsis a separate third party verification device. Once the trusted memorydevice is verified as authentic, and based on the approval of theverification algorithms included in the trusted device, the gamingmachine is enabled to verify the authenticity of additional code anddata that may be located in the gaming computer assembly, such as codeand data stored on hard disk drives. A few details related to trustedmemory devices that may be used in the present invention are describedin U.S. Pat. No. 6,685,567 from U.S. patent application Ser. No.09/925,098, filed Aug. 8, 2001 and tided “Process Verification,” whichis incorporated herein in its entirety and for all purposes.

In one or more embodiments, at least a portion of the trusted memorydevices/sources may correspond to memory which cannot easily be altered(e.g., “unalterable memory”) such as, for example, EPROMS, PROMS, Bios,Extended Bios, and/or other memory sources which are able to beconfigured, verified, and/or authenticated (e.g., for authenticity) in asecure and controlled manner.

According to a specific implementation, when a trusted informationsource is in communication with a remote device via a network, theremote device may employ a verification scheme to verify the identity ofthe trusted information source. For example, the trusted informationsource and the remote device may exchange information using public andprivate encryption keys to verify each other's identities. In anotherembodiment of the present invention, the remote device and the trustedinformation source may engage in methods using zero knowledge proofs toauthenticate each of their respective identities.

Gaming devices storing trusted information may utilize apparatus ormethods to detect and prevent tampering. For instance, trustedinformation stored in a trusted memory device may be encrypted toprevent its misuse. In addition, the trusted memory device may besecured behind a locked door. Further, one or more sensors may becoupled to the memory device to detect tampering with the memory deviceand provide some record of the tampering. In yet another example, thememory device storing trusted information might be designed to detecttampering attempts and clear or erase itself when an attempt attampering has been detected.

Additional details relating to trusted memory devices/sources aredescribed in U.S. patent application Ser. No. 11/078,966, entitled“Secured Virtual Network in a Gaming Environment”, naming Nguyen et al.as inventors, filed on Mar. 10, 2005, herein incorporated in itsentirety and for all purposes.

Mass storage devices used in a general purpose computer typically enablecode and data to be read from and written to the mass storage device. Ina gaming machine environment, modification of the gaming code stored ona mass storage device is strictly controlled and would only be enabledunder specific maintenance type events with electronic and physicalenablers required. Though this level of security could be provided bysoftware, IGT gaming computers that include mass storage devicespreferably include hardware level mass storage data protection circuitrythat operates at the circuit level to monitor attempts to modify data onthe mass storage device and will generate both software and hardwareerror triggers should a data modification be attempted without theproper electronic and physical enablers being present. Details using amass storage device that may be used with the present invention aredescribed, for example, in U.S. Pat. No. 6,149,522, herein incorporatedby reference in its entirety for all purposes.

Game Play

Returning to the example of FIG. 14, when a user wishes to play thegaming machine 2, he or she inserts a ticket or cash through the paymentor coin acceptor 28 or bill validator 30. Additionally, the billvalidator may accept a printed ticket voucher, which may be accepted bythe bill validator 30 as an indicia of credit when a cashless ticketingsystem is used. At the start of the game, the player may enter playingtracking information using the card reader 24, the keypad 22, and theflorescent display 16. Further, other game preferences of the playerplaying the game may be read from a card inserted into the card reader.During the game, the player views game information using the videodisplay 34. Other game and prize information may also be displayed inthe video display screen 45 located in the top box.

During the course of a game, a player may be required to make a numberof decisions, which affect the outcome of the game. For example, aplayer may vary his or her wager on a particular game, select a prizefor a particular game selected from a prize server, or make gamedecisions which affect the outcome of a particular game. The player maymake these choices using the player-input switches 32, the video displayscreen 34 or using some other device which enables a player to inputinformation into the gaming machine. In some embodiments, the player maybe able to access various game services such as concierge services andentertainment content services using the video display screen 34 and onemore input devices.

During certain game events, the gaming machine 2 may display visual andauditory effects that can be perceived by the player. These effects addto the excitement of a game, which makes a player more likely tocontinue playing. Auditory effects include various sounds that areprojected by the speakers 10, 12, 14. Visual effects include flashinglights, strobing lights or other patterns displayed from lights on thegaming machine 2 or from lights behind the belly glass 40. After theplayer has completed a game, the player may receive game tokens from thecoin tray 38 or the ticket 20 from the printer 18, which may be used forfurther games or to redeem a prize. Further, the player may receive aticket 20 for food, merchandise, or games from the printer 18.

In one embodiment, as described above, the gaming machine canincorporate any suitable wagering primary or base game. The gamingmachine or device may include some or all of the features ofconventional gaming machines or devices. The primary or base game maycomprise any suitable reel-type game, card game, cascading or fallingsymbol game, number game or other game of chance susceptible torepresentation in an electronic or electromechanical form, which in oneembodiment produces a random outcome based on probability data at thetime of or after placement of a wager. That is, different primarywagering games, such as video poker games, video blackjack games, videokeno, video bingo or any other suitable primary or base game may beimplemented.

In one embodiment, a base or primary game may be a slot game with one ormore paylines. The paylines may be horizontal, vertical, circular,diagonal, angled or any combination thereof. In this embodiment, thegaming machine includes at least one and preferably a plurality ofreels, such as three to five reels, in either electromechanical formwith mechanical rotating reels or video form with simulated reels andmovement thereof. In one embodiment, an electromechanical slot machineincludes a plurality of adjacent, rotatable reels, which may be combinedand operably coupled with an electronic display of any suitable type. Inanother embodiment, if the reels are in video form, one or more of thedisplay devices, as described above, display the plurality of simulatedvideo reels. Each reel displays a plurality of indicia or symbols, suchas bells, hearts, fruits, numbers, letters, bars or other images, whichpreferably correspond to a theme associated with the gaming machine. Inanother embodiment, one or more of the reels are independent reels orunisymbol reels. In this embodiment, each independent or unisymbol reelgenerates and displays one symbol to the player. In one embodiment, thegaming machine awards prizes after the reels of the primary game stopspinning if specified types and/or configurations of indicia or symbolsoccur on an active payline or otherwise occur in a winning pattern,occur on the requisite number of adjacent reels and/or occur in ascatter pay arrangement.

In an alternative embodiment, rather than determining any outcome toprovide to the player by analyzing the symbols generated on any wageredupon paylines as described above, the gaming machine determines anyoutcome to provide to the player based on the number of associatedsymbols which are generated in active symbol positions on the requisitenumber of adjacent reels (i.e., not on paylines passing through anydisplayed winning symbol combinations). In this embodiment, if a winningsymbol combination is generated on the reels, the gaming machineprovides the player one award for that occurrence of the generatedwinning symbol combination. For example, if one winning symbolcombination is generated on the reels, the gaming machine will provide asingle award to the player for that winning symbol combination (i.e.,not based on paylines that would have passed through that winning symbolcombination). It should be appreciated that because a gaming machinewith wagering on ways to win provides the player one award for a singleoccurrence of a winning symbol combination and a gaming machine withpaylines may provide the player more than one award for the sameoccurrence of a single winning symbol combination (i.e., if a pluralityof paylines each pass through the same winning symbol combination), itis possible to provide a player at a ways to win gaming machine moreways to win for an equivalent bet or wager on a traditional slot gamingmachine with paylines.

In one embodiment, the total number of ways to win is determined bymultiplying the number of symbols generated in active symbol positionson a first reel by the number of symbols generated in active symbolpositions on a second reel by the number of symbols generated in activesymbol positions on a third reel and so on for each reel of the gamingmachine with at least one symbol generated in an active symbol position.For example, a three reel gaming machine with three symbols generated inactive symbol positions on each reel includes 27 ways to win (i.e., 3symbols on the first reel×3 symbols on the second reel×3 symbols on thethird reel). A four reel gaming machine with three symbols generated inactive symbol positions on each reel includes 81 ways to win (i.e., 3symbols on the first reel×3 symbols on the second reel×3 symbols on thethird reel×3 symbols on the fourth reel). A five reel gaming machinewith three symbols generated in active symbol positions on each reelincludes 243 ways to win (i.e., 3 symbols on the first reel×3 symbols onthe second reel×3 symbols on the third reel×3 symbols on the fourthreel×3 symbols on the fifth reel). It should be appreciated thatmodifying the number of generated symbols by either modifying the numberof reels or modifying the number of symbols generated in active symbolpositions by one or more of the reels, modifies the number of ways towin.

In another embodiment, the gaming machine may enable a player to wageron and thus activate symbol positions. In one such embodiment, thesymbol positions are on the reels. In this embodiment, if based on theplayer's wager, a reel is activated, then each of the symbol positionsof that reel will be activated and each of the active symbol positionswill be part of one or more of the ways to win. In one embodiment, ifbased on the player's wager, a reel is not activated, then a designatednumber of default symbol positions, such as a single symbol position ofthe middle row of the reel, will be activated and the default symbolposition(s) will be part of one or more of the ways to win. This type ofgaming machine enables a player to wager on one, more or each of thereels and the processor of the gaming machine uses the number of wageredon reels to determine the active symbol positions and the number ofpossible ways to win. In alternative embodiments, (1) no symbols aredisplayed as generated at any of the inactive symbol positions, or (2)any symbols generated at any inactive symbol positions may be displayedto the player but suitably shaded or otherwise designated as inactive.

In one embodiment wherein a player wagers on one or more reels, aplayer's wager of one credit may activate each of the three symbolpositions on a first reel, wherein one default symbol position isactivated on each of the remaining four reels. In this example, asdescribed above, the gaming machine provides the player three ways towin (i.e., 3 symbols on the first reel×1 symbol on the second reel×1symbol on the third reel×1 symbol on the fourth reel×1 symbol on thefifth reel). In another example, a player's wager of nine credits mayactivate each of the three symbol positions on a first reel, each of thethree symbol positions on a second reel and each of the three symbolpositions on a third reel wherein one default symbol position isactivated on each of the remaining two reels. In this example, asdescribed above, the gaming machine provides the player twenty-sevenways to win (i.e., 3 symbols on the first reel×3 symbols on the secondreel×3 symbols on the third reel×1 symbol on the fourth reel×1 symbol onthe fifth reel).

In one embodiment, to determine any award(s) to provide to the playerbased on the generated symbols, the gaming machine individuallydetermines if a symbol generated in an active symbol position on a firstreel forms part of a winning symbol combination with or is otherwisesuitably related to a symbol generated in an active symbol position on asecond reel. In this embodiment, the gaming machine classifies each pairof symbols, which form part of a winning symbol combination (i.e., eachpair of related symbols) as a string of related symbols. For example, ifactive symbol positions include a first cherry symbol generated in thetop row of a first reel and a second cherry symbol generated in thebottom row of a second reel, the gaming machine classifies the twocherry symbols as a string of related symbols because the two cherrysymbols form part of a winning symbol combination.

After determining if any strings of related symbols are formed betweenthe symbols on the first reel and the symbols on the second reel, thegaming machine determines if any of the symbols from the next adjacentreel should be added to any of the formed strings of related symbols. Inthis embodiment, for a first of the classified strings of relatedsymbols, the gaming machine determines if any of the symbols generatedby the next adjacent reel form part of a winning symbol combination orare otherwise related to the symbols of the first string of relatedsymbols. If the gaming machine determines that a symbol generated on thenext adjacent reel is related to the symbols of the first string ofrelated symbols, that symbol is subsequently added to the first stringof related symbols. For example, if the first string of related symbolsis the string of related cherry symbols and a related cherry symbol isgenerated in the middle row of the third reel, the gaming machine addsthe related cherry symbol generated on the third reel to the previouslyclassified string of cherry symbols.

On the other hand, if the gaming machine determines that no symbolsgenerated on the next adjacent reel are related to the symbols of thefirst string of related symbols, the gaming machine marks or flags suchstring of related symbols as complete. For example, if the first stringof related symbols is the string of related cherry symbols and none ofthe symbols of the third reel are related to the cherry symbols of thepreviously classified string of cherry symbols, the gaming machine marksor flags the string of cherry symbols as complete.

After either adding a related symbol to the first string of relatedsymbols or marking the first string of related symbols as complete, thegaming machine proceeds as described above for each of the remainingclassified strings of related symbols which were previously classifiedor formed from related symbols on the first and second reels.

After analyzing each of the remaining strings of related symbols, thegaming machine determines, for each remaining pending or incompletestring of related symbols, if any of the symbols from the next adjacentreel, if any, should be added to any of the previously classifiedstrings of related symbols. This process continues until either eachstring of related symbols is complete or there are no more adjacentreels of symbols to analyze. In this embodiment, where there are no moreadjacent reels of symbols to analyze, the gaming machine marks each ofthe remaining pending strings of related symbols as complete.

When each of the strings of related symbols is marked complete, thegaming machine compares each of the strings of related symbols to anappropriate paytable and provides the player any award associated witheach of the completed strings of symbols. It should be appreciated thatthe player is provided one award, if any, for each string of relatedsymbols generated in active symbol positions (i.e., as opposed to beingbased on how many paylines that would have passed through each of thestrings of related symbols in active symbol positions).

In one embodiment, a base or primary game may be a poker game whereinthe gaming machine enables the player to play a conventional game ofvideo draw poker and initially deals five cards all face up from avirtual deck of fifty-two card deck. Cards may be dealt as in atraditional game of cards or in the case of the gaming machine, may alsoinclude that the cards are randomly selected from a predetermined numberof cards. If the player wishes to draw, the player selects the cards tohold via one or more input device, such as pressing related hold buttonsor via the touch screen. The player then presses the deal button and theunwanted or discarded cards are removed from the display and the gamingmachine deals the replacement cards from the remaining cards in thedeck. This results in a final five-card hand. The gaming machinecompares the final five-card hand to a payout table which utilizesconventional poker hand rankings to determine the winning hands. Thegaming machine provides the player with an award based on a winning handand the credits the player wagered.

In another embodiment, the base or primary game may be a multi-handversion of video poker. In this embodiment, the gaming machine deals theplayer at least two hands of cards. In one such embodiment, the cardsare the same cards. In one embodiment each hand of cards is associatedwith its own deck of cards. The player chooses the cards to hold in aprimary hand. The held cards in the primary hand are also held in theother hands of cards. The remaining non-held cards are removed from eachhand displayed and for each hand replacement cards are randomly dealtinto that hand. Since the replacement cards are randomly dealtindependently for each hand, the replacement cards for each hand willusually be different. The poker hand rankings are then determined handby hand and awards are provided to the player.

In one embodiment, a base or primary game may be a keno game wherein thegaming machine displays a plurality of selectable indicia or numbers onat least one of the display devices. In this embodiment, the playerselects at least one or a plurality of the selectable indicia or numbersvia an input device such as the touch screen. The gaming machine thendisplays a series of drawn numbers to determine an amount of matches, ifany, between the player's selected numbers and the gaming machine'sdrawn numbers. The player is provided an award based on the amount ofmatches, if any, based on the amount of determined matches.

In one embodiment, in addition to winning credits or other awards in abase or primary game, as described above, the gaming machine may alsogive players the opportunity to win credits in a bonus or secondary gameor bonus or secondary round. The bonus or secondary game enables theplayer to obtain a prize or payout in addition to the prize or payout,if any, obtained from the base or primary game. In general, a bonus orsecondary game produces a significantly higher level of playerexcitement than the base or primary game because it provides a greaterexpectation of winning than the base or primary game and is accompaniedwith more attractive or unusual features than the base or primary game.In one embodiment, the bonus or secondary game may be any type ofsuitable game, either similar to or completely different from the baseor primary game.

In one embodiment, the triggering event or qualifying condition may be aselected outcome in the primary game or a particular arrangement of oneor more indicia on a display device in the primary game, such as thenumber seven appearing on three adjacent reels along a payline in theprimary slot game. In other embodiments, the triggering event orqualifying condition may be by exceeding a certain amount of game play(such as number of games, number of credits, amount of time), orreaching a specified number of points earned during game play.

In another embodiment, the gaming machine processor or remote hostrandomly provides the player one or more plays of one or more secondarygames. In one such embodiment, the gaming machine does not provide anyapparent reasons to the player for qualifying to play a secondary orbonus game. In this embodiment, qualifying for a bonus game is nottriggered by an event in or based specifically on any of the plays ofany primary game. That is, the gaming machine may simply qualify aplayer to play a secondary game without any explanation or alternativelywith simple explanations. In another embodiment, the gaming machine (orremote host) qualifies a player for a secondary game at least partiallybased on a game triggered or symbol triggered event, such as at leastpartially based on the play of a primary game.

In one embodiment, the gaming machine includes a program which willautomatically begin a bonus round after the player has achieved atriggering event or qualifying condition in the base or primary game. Inanother embodiment, after a player has qualified for a bonus game, theplayer may subsequently enhance his/her bonus game participation throughcontinued play on the base or primary game. Thus, for each bonusqualifying event, such as a bonus symbol, that the player obtains, agiven number of bonus game wagering points or credits may be accumulatedin a “bonus meter” programmed to accrue the bonus wagering credits orentries toward eventual participation in a bonus game. The occurrence ofmultiple such bonus qualifying events in the primary game may result inan arithmetic or exponential increase in the number of bonus wageringcredits awarded. In one embodiment, the player may redeem extra bonuswagering credits during the bonus game to extend play of the bonus game.

In one embodiment, no separate entry fee or buy in for a bonus game needbe employed. That is, a player may not purchase an entry into a bonusgame, rather they must win or earn entry through play of the primarygame thus, encouraging play of the primary game. In another embodiment,qualification of the bonus or secondary game is accomplished through asimple “buy in” by the player, for example, if the player has beenunsuccessful at qualifying through other specified activities. Inanother embodiment, the player must make a separate side-wager on thebonus game or wager a designated amount in the primary game to qualifyfor the secondary game. In this embodiment, the secondary gametriggering event must occur and the side-wager (or designated primarygame wager amount) must have been placed to trigger the secondary game.

Gaming System Components

FIG. 15 shows a block diagram illustrating components of a gaming system1500 which may be used for implementing one or more embodiments of thepresent invention. In FIG. 15, the components of a gaming system 1500for providing game software licensing and downloads are describedfunctionally. The described functions may be instantiated in hardware,firmware and/or software and executed on a suitable device. In thesystem 1500, there may be many instances of the same function, such asmultiple game play interfaces 1511. Nevertheless, in FIG. 15, only oneinstance of each function is shown. The functions of the components maybe combined. For example, a single device may comprise the game playinterface 1511 and include trusted memory devices or sources 1509. Thedescribed components and their functions may be incorporated in variousembodiments of the cashless gaming systems, devices, and techniquesdescribed herein.

The gaming system 1500 may receive inputs from different groups/entitiesand output various services and/or information to these groups/entities.For example, game players 1525 primarily input cash or indicia of creditinto the system, make game selections that trigger software downloads,and receive entertainment in exchange for their inputs. Game softwarecontent providers provide game software for the system and may receivecompensation for the content they provide based on licensing agreementswith the gaming machine operators. Gaming machine operators select gamesoftware for distribution, distribute the game software on the gamingdevices in the system 1500, receive revenue for the use of theirsoftware and compensate the gaming machine operators. The gamingregulators 1530 may provide rules and regulations that must be appliedto the gaming system and may receive reports and other informationconfirming that rules are being obeyed.

In the following paragraphs, details of each component and some of theinteractions between the components are described with respect to FIG.15. The game software license host 1501 may be a server connected to anumber of remote gaming devices that provides licensing services to theremote gaming devices. For example, in other embodiments, the licensehost 1501 may 1) receive token requests for tokens used to activatesoftware executed on the remote gaming devices, 2) send tokens to theremote gaming devices, 3) track token usage and 4) grant and/or renewsoftware licenses for software executed on the remote gaming devices.The token usage may be used in utility based licensing schemes, such asa pay-per-use scheme.

In another embodiment, a game usage-tracking host 1515 may track theusage of game software on a plurality of devices in communication withthe host. The game usage-tracking host 1515 may be in communication witha plurality of game play hosts and gaming machines. From the game playhosts and gaming machines, the game usage tracking host 1515 may receiveupdates of an amount that each game available for play on the deviceshas been played and on amount that has been wagered per game. Thisinformation may be stored in a database and used for billing accordingto methods described in a utility based licensing agreement.

The game software host 1502 may provide game software downloads, such asdownloads of game software or game firmware, to various devious in thegame system 1500. For example, when the software to generate the game isnot available on the game play interface 1511, the game software host1502 may download software to generate a selected game of chance playedon the game play interface. Further, the game software host 1502 maydownload new game content to a plurality of gaming machines via arequest from a gaming machine operator.

In one embodiment, the game software host 1502 may also be a gamesoftware configuration-tracking host 1513. The function of the gamesoftware configuration-tracking host is to keep records of softwareconfigurations and/or hardware configurations for a plurality of devicesin communication with the host (e.g., denominations, number of paylines,paytables, max/min bets). Details of a game software host and a gamesoftware configuration host that may be used with the present inventionare described in co-pending U.S. Pat. No. 6,645,077, by Rowe, entitled,“Gaming Terminal Data Repository and Information System,” filed Dec. 21,2000, which is incorporated herein in its entirety and for all purposes.

A game play host device 1503 may be a host server connected to aplurality of remote clients that generates games of chance that aredisplayed on a plurality of remote game play interfaces 1511. Forexample, the game play host device 1503 may be a server that providescentral determination for a bingo game play played on a plurality ofconnected game play interfaces 1511. As another example, the game playhost device 1503 may generate games of chance, such as slot games orvideo card games, for display on a remote client. A game player usingthe remote client may be able to select from a number of games that areprovided on the client by the host device 1503. The game play hostdevice 1503 may receive game software management services, such asreceiving downloads of new game software, from the game software host1502 and may receive game software licensing services, such as thegranting or renewing of software licenses for software executed on thedevice 1503, from the game license host 1501.

In particular embodiments, the game play interfaces or other gamingdevices in the gaming system 1500 may be portable devices, such aselectronic tokens, cell phones, smart cards, tablet PC's and PDA's. Theportable devices may support wireless communications and thus, may bereferred to as wireless mobile devices. The network hardwarearchitecture 1516 may be enabled to support communications betweenwireless mobile devices and other gaming devices in gaming system. Inone embodiment, the wireless mobile devices may be used to play games ofchance.

The gaming system 1500 may use a number of trusted information sources.Trusted information sources 1504 may be devices, such as servers, thatprovide information used to authenticate/activate other pieces ofinformation. CRC values used to authenticate software, license tokensused to enable the use of software or product activation codes used toactivate to software are examples of trusted information that might beprovided from a trusted information source 1504. Trusted informationsources may be a memory device, such as an EPROM, that includes trustedinformation used to authenticate other information. For example, a gameplay interface 1511 may store a private encryption key in a trustedmemory device that is used in a private key-public key encryption schemeto authenticate information from another gaming device.

When a trusted information source 1504 is in communication with a remotedevice via a network, the remote device will employ a verificationscheme to verify the identity of the trusted information source. Forexample, the trusted information source and the remote device mayexchange information using public and private encryption keys to verifyeach other's identities.

Gaming devices storing trusted information might utilize apparatus ormethods to detect and prevent tampering. For instance, trustedinformation stored in a trusted memory device may be encrypted toprevent its misuse. In addition, the trusted memory device may besecured behind a locked door. Further, one or more sensors may becoupled to the memory device to detect tampering with the memory deviceand provide some record of the tampering. In yet another example, thememory device storing trusted information might be designed to detecttampering attempts and clear or erase itself when an attempt attampering has been detected.

The gaming system 1500 of the present invention may include devices 1506that provide authorization to download software from a first device to asecond device and devices 1507 that provide activation codes orinformation that enable downloaded software to be activated. Thedevices, 1506 and 1507, may be remote servers and may also be trustedinformation sources. One example of a method of providing productactivation codes that may be used with the present invention isdescribes in previously incorporated U.S. Pat. No. 6,264,561.

A device 1506 that monitors a plurality of gaming devices to determineadherence of the devices to gaming jurisdictional rules 1508 may beincluded in the system 1500. In one embodiment, a gaming jurisdictionalrule server may scan software and the configurations of the software ona number of gaming devices in communication with the gaming rule serverto determine whether the software on the gaming devices is valid for usein the gaming jurisdiction where the gaming device is located. Forexample, the gaming rule server may request a digital signature, such asCRC's, of particular software components and compare them with anapproved digital signature value stored on the gaming jurisdictionalrule server.

Further, the gaming jurisdictional rule server may scan the remotegaming device to determine whether the software is configured in amanner that is acceptable to the gaming jurisdiction where the gamingdevice is located. For example, a maximum bet limit may vary fromjurisdiction to jurisdiction and the rule enforcement server may scan agaming device to determine its current software configuration and itslocation and then compare the configuration on the gaming device withapproved parameters for its location.

A gaming jurisdiction may include rules that describe how game softwaremay be downloaded and licensed. The gaming jurisdictional rule servermay scan download transaction records and licensing records on a gamingdevice to determine whether the download and licensing was carried outin a manner that is acceptable to the gaming jurisdiction in which thegaming device is located. In general, the game jurisdictional ruleserver may be utilized to confirm compliance to any gaming rules passedby a gaming jurisdiction when the information needed to determine rulecompliance is remotely accessible to the server.

Game software, firmware or hardware residing a particular gaming devicemay also be used to check for compliance with local gamingjurisdictional rules. In one embodiment, when a gaming device isinstalled in a particular gaming jurisdiction, a software programincluding jurisdiction rule information may be downloaded to a securememory location on a gaming machine or the jurisdiction rule informationmay be downloaded as data and utilized by a program on the gamingmachine. The software program and/or jurisdiction rule information mayused to check the gaming device software and software configurations forcompliance with local gaming jurisdictional rules. In anotherembodiment, the software program for ensuring compliance andjurisdictional information may be installed in the gaming machine priorto its shipping, such as at the factory where the gaming machine ismanufactured.

The gaming devices in game system 1500 may utilize trusted softwareand/or trusted firmware. Trusted firmware/software is trusted in thesense that is used with the assumption that it has not been tamperedwith. For instance, trusted software/firmware may be used toauthenticate other game software or processes executing on a gamingdevice. As an example, trusted encryption programs and authenticationprograms may be stored on an EPROM on the gaming machine or encoded intoa specialized encryption chip. As another example, trusted gamesoftware, i.e., game software approved for use on gaming devices by alocal gaming jurisdiction may be required on gaming devices on thegaming machine.

In the present invention, the devices may be connected by a network 1516with different types of hardware using different hardware architectures.Game software can be quite large and frequent downloads can place asignificant burden on a network, which may slow information transferspeeds on the network. For game-on-demand services that require frequentdownloads of game software in a network, efficient downloading isessential for the service to remain viable. Thus, in the presentinventions, network efficient devices 1510 may be used to activelymonitor and maintain network efficiency. For instance, software locatorsmay be used to locate nearby locations of game software for peer-to-peertransfers of game software. In another example, network traffic may bemonitored and downloads may be actively rerouted to maintain networkefficiency.

One or more devices in the present invention may provide game softwareand game licensing related auditing, billing and reconciliation reportsto server 1512. For example, a software licensing billing server maygenerate a bill for a gaming device operator based upon a usage of gamesover a time period on the gaming devices owned by the operator. Inanother example, a software auditing server may provide reports on gamesoftware downloads to various gaming devices in the gaming system 1500and current configurations of the game software on these gaming devices.

At particular time intervals, the software auditing server 1512 may alsorequest software configurations from a number of gaming devices in thegaming system. The server may then reconcile the software configurationon each gaming device. In one embodiment, the software auditing server1512 may store a record of software configurations on each gaming deviceat particular times and a record of software download transactions thathave occurred on the device. By applying each of the recorded gamesoftware download transactions since a selected time to the softwareconfiguration recorded at the selected time, a software configuration isobtained. The software auditing server may compare the softwareconfiguration derived from applying these transactions on a gamingdevice with a current software configuration obtained from the gamingdevice. After the comparison, the software-auditing server may generatea reconciliation report that confirms that the download transactionrecords are consistent with the current software configuration on thedevice. The report may also identify any inconsistencies. In anotherembodiment, both the gaming device and the software auditing server maystore a record of the download transactions that have occurred on thegaming device and the software auditing server may reconcile theserecords.

There are many possible interactions between the components describedwith respect to FIG. 15. Many of the interactions are coupled. Forexample, methods used for game licensing may affect methods used forgame downloading and vice versa. For the purposes of explanation,details of a few possible interactions between the components of thesystem 1500 relating to software licensing and software downloads havebeen described. The descriptions are selected to illustrate particularinteractions in the game system 1500. These descriptions are providedfor the purposes of explanation only and are not intended to limit thescope of the present invention.

Gaming System Configuration

In one embodiment, as described above, the present invention may beimplemented in various configurations for gaming machines, including butnot limited to: (1) a dedicated gaming machine, wherein the computerizedinstructions for controlling any games (which are provided by the gamingmachine) are provided with the gaming machine prior to delivery to agaming establishment; and (2) a changeable gaming machine, where thecomputerized instructions for controlling any games (which are providedby the gaming machine) are downloadable to the gaming machine through adata network when the gaming machine is in a gaming establishment. Inanother embodiment, the computerized instructions for controlling anygames are communicated from the remote host, the central server orcentral controller to a gaming machine local processor and memorydevices. In such a “thick client” embodiment, the gaming machine localprocessor executes the communicated computerized instructions to controlany games (or other suitable interfaces) provided to a player.

In one alternative embodiment, the computerized instructions forcontrolling any games are executed by a remote host, a central server orcentral controller. In such a “thin client” embodiment, the remote hostremotely controls any games (or other suitable interfaces) and thegaming machine is utilized to display such games (or suitableinterfaces) and receive one or more inputs or commands from a player. Inone embodiment, one or more gaming machines in a gaming system may bethin client gaming machines and one or more gaming machines in thegaming system may be thick client gaming machines. In anotherembodiment, certain functions of the gaming machine are implemented in athin client environment and certain other functions of the gamingmachine are implemented in a thick client environment. In one suchembodiment, computerized instructions for controlling any primary gamesare communicated from the remote host to the gaming machine in a thickclient configuration and computerized instructions for controlling anysecondary games or bonus functions are executed by a remote host in athin client configuration. It should be appreciated that one, more oreach of the functions of the remote host as disclosed herein may beperformed by one or more gaming machine processors. It should be furtherappreciated that one, more or each of the functions of one or moregaming machine processors as disclosed herein may be performed by theremote host.

In one embodiment, the gaming machine randomly generates awards and/orother game outcomes based on probability data. In one such embodiment,this random determination is provided through utilization of a randomnumber generator (RNG), such as a true random number generator, a pseudorandom number generator or other suitable randomization process. In oneembodiment, each award or other game outcome is associated with aprobability and the gaming machine generates the award or other gameoutcome to be provided to the player based on the associatedprobabilities. In this embodiment, since the gaming machine generatesoutcomes randomly or based upon one or more probability calculations,there is no certainty that the gaming machine will ever provide theplayer with any specific award or other game outcome.

In an alternative embodiment, the remote host maintains one or morepredetermined pools or sets of predetermined game outcomes. In thisembodiment, the remote host receives the game outcome request andindependently selects a predetermined game outcome from a set or pool ofgame outcomes. The remote host flags or marks the selected game outcomeas used. Once a game outcome is flagged as used, it is prevented fromfurther selection from the set or pool and cannot be selected by theremote host upon another wager. The provided game outcome can include aprimary game outcome, a secondary game outcome, primary and secondarygame outcomes, or a series of game outcomes such as free games.

The remote host communicates the generated or selected game outcome tothe initiated gaming machine. The gaming machine receives the generatedor selected game outcome and provides the game outcome to the player. Inan alternative embodiment, how the generated or selected game outcome isto be presented or displayed to the player, such as a reel symbolcombination of a slot machine or a hand of cards dealt in a card game,is also determined by the remote host and communicated to the initiatedgaming machine to be presented or displayed to the player. Centralproduction or control can assist a gaming establishment or other entityin maintaining appropriate records, controlling gaming, reducing andpreventing cheating or electronic or other errors, reducing oreliminating win-loss volatility and the like.

In another embodiment, a predetermined game outcome value is determinedfor each of a plurality of linked or networked gaming machines based onthe results of a bingo, keno or lottery game. In this embodiment, eachindividual gaming machine utilizes one or more bingo, keno or lotterygames to determine the predetermined game outcome value provided to theplayer for the interactive game played at that gaming machine. In oneembodiment, the bingo, keno or lottery game is displayed to the player.In another embodiment, the bingo, keno or lottery game is not displayedto the player, but the results of the bingo, keno or lottery gamedetermine the predetermined game outcome value for the primary orsecondary game.

In the various bingo embodiments, as each gaming machine is enrolled inthe bingo game, such as upon an appropriate wager or engaging an inputdevice, the enrolled gaming machine is provided or associated with adifferent bingo card. Each bingo card consists of a matrix or array ofelements, wherein each element is designated with a separate indicia,such as a number. It should be appreciated that each different bingocard includes a different combination of elements. For example, if fourbingo cards are provided to four enrolled gaming machines, the sameelement may be present on all four of the bingo cards while anotherelement may solely be present on one of the bingo cards.

In operation of these embodiments, upon providing or associating adifferent bingo card to each of a plurality of enrolled gaming machines,the remote host randomly selects or draws, one at a time, a plurality ofthe elements. As each element is selected, a determination is made foreach gaming machine as to whether the selected element is present on thebingo card provided to that enrolled gaming machine. This determinationcan be made by the remote host, the gaming machine, a combination of thetwo, or in any other suitable manner. If the selected element is presenton the bingo card provided to that enrolled gaming machine, thatselected element on the provided bingo card is marked or flagged. Thisprocess of selecting elements and marking any selected elements on theprovided bingo cards continues until one or more predetermined patternsare marked on one or more of the provided bingo cards. It should beappreciated that in one embodiment, the gaming machine requires theplayer to engage a daub button (not shown) to initiate the process ofthe gaming machine marking or flagging any selected elements.

After one or more predetermined patterns are marked on one or more ofthe provided bingo cards, a game outcome is determined for each of theenrolled gaming machines based, at least in part, on the selectedelements on the provided bingo cards. As described above, the gameoutcome determined for each gaming machine enrolled in the bingo game isutilized by that gaming machine to determine the predetermined gameoutcome provided to the player. For example, a first gaming machine tohave selected elements marked in a predetermined pattern is provided afirst outcome of win $10 which will be provided to a first playerregardless of how the first player plays in a first game and a secondgaming machine to have selected elements marked in a differentpredetermined pattern is provided a second outcome of win $2 which willbe provided to a second player regardless of how the second player playsa second game. It should be appreciated that as the process of markingselected elements continues until one or more predetermined patterns aremarked, this embodiment insures that at least one bingo card will winthe bingo game and thus at least one enrolled gaming machine willprovide a predetermined winning game outcome to a player. It should beappreciated that other suitable methods for selecting or determining oneor more predetermined game outcomes may be employed.

In one example of the above-described embodiment, the predetermined gameoutcome may be based on a supplemental award in addition to any awardprovided for winning the bingo game as described above. In thisembodiment, if one or more elements are marked in supplemental patternswithin a designated number of drawn elements, a supplemental orintermittent award or value associated with the marked supplementalpattern is provided to the player as part of the predetermined gameoutcome. For example, if the four corners of a bingo card are markedwithin the first twenty selected elements, a supplemental award of $10is provided to the player as part of the predetermined game outcome. Itshould be appreciated that in this embodiment, the player of a gamingmachine may be provided a supplemental or intermittent award regardlessof if the enrolled gaming machine's provided bingo card wins or does notwin the bingo game as described above.

In another embodiment, the game outcome provided to the player isdetermined by a remote host and provided to the player at the gamingmachine. In this embodiment, each of a plurality of such gaming machinesare in communication with the remote host. Upon a player initiating gameplay at one of the gaming machines, the initiated gaming machinecommunicates a game outcome request to the remote host. In oneembodiment, the remote host receives the game outcome request andrandomly generates a game outcome for the primary game based onprobability data. In another embodiment, the remote host randomlygenerates a game outcome for the secondary game based on probabilitydata. In another embodiment, the remote host randomly generates a gameoutcome for both the primary game and the secondary game based onprobability data. In this embodiment, the remote host is capable ofstoring and utilizing program code or other data similar to theprocessor and memory device of the gaming machine.

In another embodiment, one or more of the gaming machines are incommunication with a remote host for monitoring purposes. In oneembodiment, the gaming network includes a real-time or on-lineaccounting and gaming information system operably coupled to the remotehost. The accounting and gaming information system of this embodimentincludes a player database for storing player profiles, a playertracking module for tracking players and a credit system for providingautomated casino transactions.

In another embodiment, a plurality of gaming machines at one or moregaming sites may be networked to the remote host in a progressiveconfiguration, as known in the art, wherein a portion of each wager toinitiate a base or primary game may be allocated to one or moreprogressive awards. In one embodiment, a progressive gaming system hostsite computer is coupled to a plurality of the remote hosts at a varietyof mutually remote gaming sites for providing a multi-site linkedprogressive automated gaming system. In one embodiment, a progressivegaming system host site computer may serve gaming machines distributedthroughout a number of properties at different geographical locationsincluding, for example, different locations within a city or differentcities within a state.

In one embodiment, the progressive gaming system host site computer ismaintained for the overall operation and control of the progressivegaming system. In this embodiment, a progressive gaming system host sitecomputer oversees the entire progressive gaming system and is the masterfor computing all progressive jackpots. All participating gaming sitesreport to, and receive information from, the progressive gaming systemhost site computer. Each remote host computer is responsible for alldata communication between the gaming machine hardware and software andthe progressive gaming system host site computer. In one embodiment, anindividual gaming machine may trigger a progressive award win. Inanother embodiment, a remote host (or the progressive gaming system hostsite computer) determines when a progressive award win is triggered. Inanother embodiment, an individual gaming machine and a remote host (orprogressive gaming system host site computer) work in conjunction witheach other to determine when a progressive win is triggered, for examplethrough an individual gaming machine meeting a predetermined requirementestablished by the remote host.

In one embodiment, a progressive award win is triggered based on one ormore game play events, such as a symbol-driven trigger. In otherembodiments, the progressive award triggering event or qualifyingcondition may be by exceeding a certain amount of game play (such asnumber of games, number of credits, or amount of time), or reaching aspecified number of points earned during game play. In anotherembodiment, a gaming machine is randomly or apparently randomly selectedto provide a player of that gaming machine one or more progressiveawards. In one such embodiment, the gaming machine does not provide anyapparent reasons to the player for winning a progressive award, whereinwinning the progressive award is not triggered by an event in or basedspecifically on any of the plays of any primary game. That is, a playeris provided a progressive award without any explanation or alternativelywith simple explanations. In another embodiment, a player is provided aprogressive award at least partially based on a game triggered or symboltriggered event, such as at least partially based on the play of aprimary game.

In one embodiment, one or more of the progressive awards are each fundedvia a side bet or side wager. In this embodiment, a player must place orwager a side bet to be eligible to win the progressive award associatedwith the side bet. In one embodiment, the player must place the maximumbet and the side bet to be eligible to win one of the progressiveawards. In another embodiment, if the player places or wagers therequired side bet, the player may wager at any credit amount during theprimary game (i.e., the player need not place the maximum bet and theside bet to be eligible to win one of the progressive awards). In onesuch embodiment, the greater the player's wager (in addition to theplaced side bet), the greater the odds or probability that the playerwill win one of the progressive awards. It should be appreciated thatone or more of the progressive awards may each be funded, at least inpart, based on the wagers placed on the primary games of the gamingmachines in the gaming system, via a gaming establishment or via anysuitable manner.

In another embodiment, one or more of the progressive awards arepartially funded via a side-bet or side-wager which the player may make(and which may be tracked via a side-bet meter). In one embodiment, oneor more of the progressive awards are funded with only side-bets orside-wagers placed. In another embodiment, one or more of theprogressive awards are funded based on player's wagers as describedabove as well as any side-bets or side-wagers placed.

In one alternative embodiment, a minimum wager level is required for agaming machine to qualify to be selected to obtain one of theprogressive awards. In one embodiment, this minimum wager level is themaximum wager level for the primary game in the gaming machine. Inanother embodiment, no minimum wager level is required for a gamingmachine to qualify to be selected to obtain one of the progressiveawards.

In another embodiment, the gaming system maintains at least oneprogressive award by allocating a percentage of a player's wager intothe player's own progressive award or pool (i.e., a personal progressiveaward). In this embodiment, upon the occurrence of an event (eitherassociated with game play or independent of game play), the gamingsystem provides the player their personal progressive award.

In another embodiment, a plurality of players at a plurality of linkedgaming machines in a gaming system participate in a group gamingenvironment. In one embodiment, a plurality of players at a plurality oflinked gaming machines work in conjunction with one another, such asplaying together as a team or group, to win one or more awards. In onesuch embodiment, any award won by the group is shared, either equally orbased on any suitable criteria, amongst the different players of thegroup. In another embodiment, a plurality of players at a plurality oflinked gaming machines compete against one another for one or moreawards. In one such embodiment, a plurality of players at a plurality oflinked gaming machines participate in a gaming tournament for one ormore awards. In another embodiment, a plurality of players at aplurality of linked gaming machines play for one or more awards whereinan outcome generated by one gaming machine affects the outcomesgenerated by one or more linked gaming machines.

Some networks described herein provide methods and devices for managingone or more networked gaming establishments. Such networks may sometimesbe referred to herein as server-based gaming networks, Sb™ networks, orthe like. Some such gaming networks described herein allow for theconvenient provisioning of networked gaming machines and other devicesrelevant to casino operations. Game themes may be easily andconveniently added or changed, if desired. Related software, includingbut not limited to player tracking software, peripheral software, etc.,may be downloaded to networked gaming machines, mobile gaming devices,thin clients and/or other devices, such as kiosks, networked gamingtables, player stations, etc.

In some implementations, servers or other devices of a central systemwill determine game outcomes and/or provide other wager gamingfunctionality. In some such implementations, wagering games may beexecuted primarily on one or more devices of a central system, such as aserver, a host computer, etc. For example, wager gaming determinations(such as interim and final game outcomes, bonuses, etc.) may be made byone or more servers or other networked devices. Player trackingfunctions, accounting functions and even some display-related functionsassociated with wagering games may be performed, at least in part, byone or more devices of casino network and/or of a central system.

FIG. 16 shows a server-based (Sb™) gaming network, which may be used forimplementing one or more embodiments of the present invention. Those ofskill in the art will realize that this architecture and the relatedfunctionality are merely examples and that the present inventionencompasses many other such embodiments and methods.

Here, casino computer room 1620 and networked devices of a gamingestablishment 1605 are illustrated. Gaming establishment 1605 isconfigured for communication with central system 1663 via gateway 1650.Gaming establishments 1693 and 1695 are also configured forcommunication with central system 1663.

In some implementations, gaming establishments may be configured forcommunication with one another. In this example, gaming establishments1693 and 1695 are configured for communication with casino computer room1620. Such a configuration may allow devices and/or operators in casino1605 to communicate with and/or control devices in other casinos. Insome such implementations, a server in computer room 1620 may controldevices in casino 1605 and devices in other gaming establishments.Conversely, devices and/or operators in another gaming establishment maycommunicate with and/or control devices in casino 1605.

For example, a server of casino 1605 or central system 1663 may beprovisioned with relatively more advanced software (e.g., 3-D facialrecognition software) for patron identification than servers of othernetworked locations. Such a server may process patron identificationrequests from devices in casino 1605 as well as patron identificationrequests from devices in gaming establishments 1693 and 1695.

Here, gaming establishment 1697 is configured for communication withcentral system 1663, but is not configured for communication with othergaming establishments. Some gaming establishments (not shown) may not bein communication with other gaming establishments or with a centralsystem. Gaming establishment 1605 includes multiple gaming machines1621, each of which is part of a bank 1610 of gaming machines 1621. Inthis example, gaming establishment 1605 also includes a bank ofnetworked gaming tables 1653. However, the present invention may beimplemented in gaming establishments having any number of gamingmachines, gaming tables, etc. It will be appreciated that many gamingestablishments include hundreds or even thousands of gaming machines1621 and/or gaming tables 1653, not all of which are necessarilyincluded in a bank and some of which may not be connected to a network.At least some of gaming machines 1621 and/or mobile devices 1670 may be“thin clients” that are configured to perform client-side methods asdescribed elsewhere herein.

Some gaming networks provide features for gaming tables that are similarto those provided for gaming machines, including but not limited tobonusing, player loyalty/player tracking and the use of cashlessinstruments. Relevant material is provided in U.S. Pat. No. 8,602,874,entitled “CASHLESS INSTRUMENT BASED TABLE GAME PROMOTIONAL SYSTEM ANDMETHODOLOGY”; U.S. Provisional Patent Application No. 60/858,046,entitled “AUTOMATED PLAYER DATA COLLECTION SYSTEM FOR TABLE GAMEENVIRONMENTS” and filed on Nov. 10, 2006; U.S. Patent Appl. Pub. No.2006/0258427, entitled “WIDE AREA TABLE GAMING MONITOR AND CONTROLSYSTEM”; U.S. Patent Appl. Pub. No. 2007/0298873, entitled “PROGRESSIVETABLE GAME BONUSING SYSTEMS AND METHODS”; and U.S. Pat. No. 7,997,981,entitled “UNIVERSAL CASINO BONUSING SYSTEMS AND METHODS”, all of whichare incorporated herein by reference. Accordingly, software related tosuch features may be provided and/or controlled, and related data may beobtained and/or provided, according to the present invention.

Some configurations can provide automated, multi-player roulette,blackjack, baccarat, and other table games. The table games may beconducted by a dealer and/or by using some form of automation, which mayinclude an automated roulette wheel, an electronic representation of adealer, etc. In some such implementations, devices such as cameras,radio frequency identification devices, etc., may be used to identifyand/or track playing cards, chips, etc. Some of gaming tables 1653 maybe configured for communication with individual player terminals (notshown), which may be configured to accept bets, present an electronicrepresentation of a dealer, indicate game outcomes, etc.

Some gaming networks include electronically configurable tables forplaying table games. U.S. Pat. No. 8,545,326, entitled “CASINO DISPLAYMETHODS AND DEVICES”, describes some such tables and is herebyincorporated by reference. An operator may select a desired game, suchas a poker game or a blackjack game, and the table will be automaticallyconfigured with geometrical patterns, text, etc., which are appropriatefor the desired table game. The desired type of table game may beselected by a control on the table itself or according to instructionsreceived from, e.g., a server or a casino manager via a networkinterface.

Gaming establishment 1605 also includes networked kiosks 1677. Dependingon the implementation, kiosks 1677 may be used for various purposes,including but not limited to cashing out, prize redemption, redeemingpoints from a player loyalty program, redeeming “cashless” indicia suchas bonus tickets, smart cards, etc. In some implementations, kiosks 1677may be used for obtaining information about the gaming establishment,e.g., regarding scheduled events (such as tournaments, entertainment,etc.), regarding a patron's location, etc. Software related to suchfeatures may be provided and/or controlled, and related data may beobtained and/or provided, according to the present invention. Forexample, in some implementations of the invention, kiosks 1677 may beconfigured to receive information from a patron, e.g., by presentinggraphical user interfaces.

In this example, each bank 1610 has a corresponding switch 1615, whichmay be a conventional bank switch in some implementations. Each switch1615 is configured for communication with one or more devices incomputer room 1620 via main network device 1625, which combinesswitching and routing functionality in this example. Although variouscommunication protocols may be used, some preferred implementations usethe Gaming Standards Association's G2S Message Protocol. Otherimplementations may use IGT's open, Ethernet-based SuperSAS® protocol,which IGT makes available for downloading without charge. Still otherprotocols, including but not limited to Best of Breed (“BOB”), may beused to implement various embodiments of the invention. IGT has alsodeveloped a gaming-industry-specific transport layer called CASH thatrides on top of TCP/IP and offers additional functionality and security.

Here, gaming establishment 1605 also includes an RFID network,implemented in part by RFID switches 1619 and multiple RFID readers1617. An RFID network may be used, for example, to track objects (suchas mobile gaming devices 1670, which include RFID tags 1627 in thisexample), patrons, etc., in the vicinity of gaming establishment 1605.Some examples of how an RFID network may be used in a gamingestablishment are set forth in U.S. Pat. No. 8,430,749, entitled“DYNAMIC CASINO TRACKING AND OPTIMIZATION,” and in U.S. Patent Appl.Pub. No. 2007/0060394, entitled “DOWNLOADING UPON THE OCCURRENCE OFPREDETERMINED EVENTS,” all of which are hereby incorporated byreference.

As noted elsewhere herein, some implementations of the invention mayinvolve “smart” player loyalty instruments, such as player trackingcards, which include an RFID tag. Accordingly, the location of suchRFID-enabled player loyalty instruments may be tracked via the RFIDnetwork. In this example, at least some of mobile devices 1670 mayinclude an RFID tag 1627, which includes encoded identificationinformation for the mobile device 1670. Accordingly, the locations ofsuch tagged mobile devices 1670 may be tracked via the RFID network ingaming establishment 1605. Other location-detection devices and systems,such as the global positioning system (“GPS”), may be used to monitorthe location of people and/or devices in the vicinity of gamingestablishment 1605 or elsewhere.

Various alternative network topologies can be used to implementdifferent embodiments of the invention and/or to accommodate varyingnumbers of networked devices. For example, gaming establishments withlarge numbers of gaming machines 1621 may require multiple instances ofsome network devices (e.g., of main network device 1625, which combinesswitching and routing functionality in this example) and/or theinclusion of other network devices not shown in FIG. 16. Someimplementations of the invention may include one or more middlewareservers disposed between kiosks 1677, RFID switches 1619 and/or bankswitches 1615 and one or more devices in computer room 1620 (e.g., acorresponding server). Such middleware servers can provide varioususeful functions, including but not limited to the filtering and/oraggregation of data received from switches, from individual gamingmachines and from other devices. Some implementations of the inventioninclude load-balancing methods and devices for managing network traffic.

Storage devices 1611, Sb™ server 1630, License Manager 1631, Arbiter1633, servers 1632, 1634, 1636 and 16316, host device(s) 1660 and mainnetwork device 1625 are disposed within computer room 1620 of gamingestablishment 1605. In practice, more or fewer devices may be used.Depending on the implementation, some such devices may reside in gamingestablishment 1605 or elsewhere.

One or more devices in central system 1663 may also be configured toperform, at least in part, tasks specific to the present invention. Forexample, one or more servers 1662, arbiter 1633, storage devices 1664and/or host devices 1660 of central system 1663 may be configured toimplement the functions described in detail elsewhere herein. Thesefunctions may include, but are not limited to, providing functionalityfor devices such as wager gaming machines 1621, mobile devices 1670,etc.

One or more of the servers of computer room 1620 may be configured withsoftware for receiving a player's wager gaming notification parameters,determining when a wagering condition corresponds with the wager gamingnotification parameters and/or providing a notification to the playerwhen the wagering condition corresponds with the wager gamingnotification parameters. Moreover, one or more of the servers may beconfigured to receive, process and/or provide image data from cameras1609, to provide navigation data to patrons (e.g., to indicate thelocation of and/or directions to a gaming table, a wager gaming machine,etc., associated with a wager gaming notification), etc.

For example, navigation data (which may include map data, casino layoutdata, camera image data, etc.) may be provided by one or more of theservers of computer room 1620 to mobile devices 1670. Someimplementations of the present invention include a plurality ofnetworked cameras 1609, which may be video cameras, smart cameras,digital still cameras, etc. In some such implementations, such camerasmay provide, at least in part, real-time navigation features such asthose described in U.S. Patent Appl. Pub. No. 2009/0265105, entitled“Real-Time Navigation Devices, Systems and Methods,” which isincorporated herein by reference.

Other devices that may be deployed in network 1605 do not appear in FIG.16. For example, some gaming networks may include not only various radiofrequency identification (“RFID”) readers 1617, but also RFID switches,middleware servers, etc., some of which are not depicted in FIG. 16.These features may provide various functions. For example, a server (oranother device) may determine a location of a mobile device 1670according to the location of an RFID reader that reads an RFID tag 1627.

The servers and other devices indicated in FIG. 16 may be configured forcommunication with other devices in or outside of gaming establishment1605, such as host devices 1660, kiosks 1677 and/or mobile devices 1670,for implementing some methods described elsewhere herein. Servers (orthe like) may facilitate communications with such devices, receive andstore patron data, provide appropriate responses, etc., as describedelsewhere herein.

Some of these servers may be configured to perform tasks relating toaccounting, player loyalty, bonusing/progressives, configuration ofgaming machines, etc. One or more such devices may be used to implementa casino management system, such as the IGT Advantage™ Casino Systemsuite of applications, which provides instantaneous information that maybe used for decision-making by casino managers. A Radius server and/or aDHCP server may also be configured for communication with the gamingnetwork. Some implementations of the invention provide one or more ofthese servers in the form of blade servers.

Some preferred embodiments of Sb™ server 1630 and the other serversshown in FIG. 16 include (or are at least in communication with)clustered CPUs, redundant storage devices, including backup storagedevices, switches, etc. Such storage devices may include a “RAID”(originally redundant array of inexpensive disks, now also known asredundant array of independent disks) array, back-up hard drives and/ortape drives, etc.

In some implementations of the invention, many of these devices(including but not limited to License Manager 1631, servers 1632, 1634,1636 and 16316, and main network device 1625) are mounted in a singlerack with Sb™ server 1630. Accordingly, many or all such devices willsometimes be referenced in the aggregate as an “Sb™ server.” However, inalternative implementations, one or more of these devices is incommunication with Sb™ server 1630 and/or other devices of the networkbut located elsewhere. For example, some of the devices could be mountedin separate racks within computer room 1620 or located elsewhere on thenetwork. Moreover, it can be advantageous to store large volumes of dataelsewhere via a storage area network (“SAN”).

Computer room 1620 may include one or more operator consoles or otherhost devices that are configured for communication with other deviceswithin and outside of computer room 1620. Such host devices may beprovided with software, hardware and/or firmware for implementingvarious embodiments of the invention. However, such host devices neednot be located within computer room 1620. Wired host devices 1660 (whichare desktop and laptop computers in this example) and wireless devices1670 (which are PDAs in this example) may be located elsewhere in gamingestablishment 1605 or at a remote location.

Although the foregoing present invention has been described in detail byway of illustration and example for purposes of clarity andunderstanding, it will be recognized that the above described presentinvention may be embodied in numerous other specific variations andembodiments without departing from the spirit or essentialcharacteristics of the present invention. Certain changes andmodifications may be practiced, and it is understood that the presentinvention is not to be limited by the foregoing details, but rather isto be defined by the scope of the appended claims.

The invention is claimed as follows:
 1. A method of operating a gamingdevice, the method comprising: (a) establishing communications, by acommunication interface, with a portable electronic device that stores aportable electronic device credit balance; (b) establishing, by at leastone processor, a gaming device credit balance; (c) enabling play of awagering game on the gaming device using the gaming device creditbalance; (d) monitoring, by the at least one processor, the gamingdevice credit balance with respect to an auto-transfer threshold; and(e) if the gaming device credit balance falls below the auto-transferthreshold: (1) automatically transmitting, by the communicationinterface and to the portable electronic device, a request for atransfer of a designated quantity of credits, the request includingsecurity authorization information; and (2) if the portable electronicdevice determines that the request complies with one or more securityauthorization requirements: (i) receiving, by the communicationinterface and from the portable electronic device, an indication thatthe portable electronic device credit balance has been decreased by thedesignated quantity of credits; and (ii) increasing, by the at least oneprocessor, the gaming device credit balance by the designated quantityof credits.
 2. The method of claim 1, wherein the designated quantity ofcredits is predetermined.
 3. The method of claim 1, wherein the portableelectronic device is a mobile phone.
 4. The method of claim 1, whereinthe communication interface includes a card reader and the portableelectronic device includes a card.
 5. The method of claim 1, whichincludes, if the gaming device credit balance falls below theauto-transfer threshold, receiving, by an input device, anidentification code, the security authorization information includingthe identification code.
 6. The method of claim 1, wherein establishingcommunications with the portable electronic device includes establishingwireless communications, by the communication interface, with theportable electronic device.
 7. The method of claim 1, whereinestablishing the gaming device credit balance includes: receiving, by aninput device, a credit transfer request; transmitting, by thecommunication interface and to the portable electronic device, a requestfor a transfer of an initial quantity of credits, the request includingsecond security authorization information; and if the portableelectronic device determines that the request complies with one or moresecond security authorization requirements: (i) receiving, by thecommunication interface and from the portable electronic device, anindication that the portable electronic device credit balance has beendecreased by the initial quantity of credits; and (ii) increasing, bythe at least one processor, the gaming device credit balance by theinitial quantity of credits.
 8. The method of claim 1, which includes:(f) receiving, by the communication interface and from the portableelectronic device, authentication information; (g) transmitting, by thecommunication interface and to an authentication server, theauthentication information; and (h) receiving, by the communicationinterface and from the authentication server, an indication of whetherthe portable electronic device is authentic.
 9. The method of claim 8,which includes performing (f) to (h) after establishing communicationswith the portable electronic device and before establishing the gamingdevice credit balance.
 10. The method of claim 1, which includes:receiving, by an input device, a cash out input; transmitting, by thecommunication interface and to the portable electronic device, a requestto transfer the gaming device credit balance to the portable electronicdevice; and if the portable electronic device determines that therequest complies with one or more second security authorizationrequirements: (i) receiving, by the communication interface and from theportable electronic device, an indication that the portable electronicdevice credit balance has been increased by the quantity of credits inthe gaming device credit balance; and (ii) decreasing, by the at leastone processor, the gaming device credit balance by the quantity ofcredits in the gaming device credit balance.
 11. A gaming devicecomprising: a housing; a communication interface supported by thehousing; a plurality of input devices supported by the housing andincluding an acceptor configured to receive a physical item associatedwith a monetary value; at least one display device supported by thehousing; at least one processor; and at least one memory device thatstores a plurality of instructions that, when executed by the at leastone processor, cause the at least one processor to operate with thecommunication interface, the plurality of input devices, and the atleast one display device to: (a) establish communications with aportable electronic device that stores a portable electronic devicecredit balance; (b) establish a gaming device credit balance; (c) enableplay of a wagering game on the gaming device using the gaming devicecredit balance; (d) monitor the gaming device credit balance withrespect to an auto-transfer threshold; and (e) if the gaming devicecredit balance falls below the auto-transfer threshold: (1)automatically transmit, to the portable electronic device, a request fora transfer of a designated quantity of credits, the request includingsecurity authorization information; and (2) if the portable electronicdevice determines that the request complies with one or more securityauthorization requirements: (i) receive, from the portable electronicdevice, an indication that the portable electronic device credit balancehas been decreased by the designated quantity of credits; and (ii)increase the gaming device credit balance by the designated quantity ofcredits.
 12. The gaming device of claim 11, wherein the designatedquantity of credits is predetermined.
 13. The gaming device of claim 11,wherein the portable electronic device is a mobile phone.
 14. The gamingdevice of claim 11, wherein the communication interface includes a cardreader and the portable electronic device includes a card.
 15. Thegaming device of claim 11, wherein the plurality of instructions, whenexecuted by the at least one processor, cause the at least one processorto operate with one of the plurality of input devices to, if the gamingdevice credit balance falls below the auto-transfer threshold, receivean identification code, the security authorization information includingthe identification code.
 16. The gaming device of claim 11, wherein theplurality of instructions, when executed by the at least one processor,cause the at least one processor to establish communications with theportable electronic device by establishing wireless communications withthe portable electronic device.
 17. The gaming device of claim 11,wherein the plurality of instructions, when executed by the at least oneprocessor, cause the at least one processor to operate with thecommunication interface and one of the plurality of input devices toestablish the gaming device credit balance by: receiving, by said one ofthe plurality of input devices, a credit transfer request; transmitting,by the communication interface and to the portable electronic device, arequest for a transfer of an initial quantity of credits, the requestincluding second security authorization information; and if the portableelectronic device determines that the request complies with one or moresecond security authorization requirements: (i) receiving, by thecommunication interface and from the portable electronic device, anindication that the portable electronic device credit balance has beendecreased by the initial quantity of credits; and (ii) increasing, bythe at least one processor, the gaming device credit balance by theinitial quantity of credits.
 18. The gaming device of claim 11, whereinthe plurality of instructions, when executed by the at least oneprocessor, cause the at least one processor to operate with thecommunication interface to: (f) receive, from the portable electronicdevice, authentication information; (g) transmit, to an authenticationserver, the authentication information; and (h) receive, from theauthentication server, an indication of whether the portable electronicdevice is authentic.
 19. The gaming device of claim 18, wherein theplurality of instructions, when executed by the at least one processor,cause the at least one processor to perform (f) to (h) afterestablishing communications with the portable electronic device andbefore establishing the gaming device credit balance.
 20. The gamingdevice of claim 11, wherein the plurality of instructions, when executedby the at least one processor, cause the at least one processor tooperate with the communication interface and one of the plurality ofinput devices to: receive a cash out input; transmit, to the portableelectronic device, a request to transfer the gaming device creditbalance to the portable electronic device; and if the portableelectronic device determines that the request complies with one or moresecond security authorization requirements: (i) receive, from theportable electronic device, an indication that the portable electronicdevice credit balance has been increased by the quantity of credits inthe gaming device credit balance; and (ii) decrease the gaming devicecredit balance by the quantity of credits in the gaming device creditbalance.